Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

R1CH · Tue Jun 18, 2019 12:33 am

A bunch of MSS related TCP bugs were found in the Linux kernel that can result in remote denial of service. Details: https://github.com/Netflix/security-bul ... d#advisory

Since RouterOS is based on older Linux kernel, if you have any open TCP ports then you are likely vulnerable. Note that RouterOS default config firewall will protect you from this, only if you have open ports are you at risk from internet-based attacks.

Workaround is to add this to the top of your input rules. Adjust MSS as needed if you have some weird clients:

/ip firewall filter add action=drop chain=input comment="CVE-2019-11477, CVE-2019-11478, CVE-2019-11479" protocol=tcp tcp-flags=syn tcp-mss=0-500

mkx · Tue Jun 18, 2019 8:14 am

How safe and resource-hungry would it be to include also rule

/ip firewall filter add action=drop chain=forward comment="CVE-2019-11477, CVE-2019-11478, CVE-2019-11479" protocol=tcp tcp-flags=syn tcp-mss=0-500

to potentially protect linux/BSD hosts behind the firewall? Let's assume that non-firewalled access to those won't trigger the bug ...

JasonEde · Tue Jun 18, 2019 11:01 am

Surely it's more cpu efficient to detect and add users to a dynamic address list which you then drop in raw?
I can't imagine you'd want to accept traffic from someone trying to kill your systems?

kobuki · Tue Jun 18, 2019 12:23 pm

There are fixes in kernel upstream for these vulnerabilities. Will Mikrotik apply them in a security release?

msatter · Tue Jun 18, 2019 12:43 pm

Till we have a conformation about this, from Mikrotik put that rule in RAW. Which is the best place for it.

R1CH · Tue Jun 18, 2019 2:40 pm

Surely it's more cpu efficient to detect and add users to a dynamic address list which you then drop in raw?
I can't imagine you'd want to accept traffic from someone trying to kill your systems?

Dropping the initial SYN is enough to stop the connection, other packets and fragments will just be ignored by the kernel. Adding to address lists and checking all inbound packets would use more CPU, plus since this isn't a confirmed connection (SYN can be spoofed), you risk adding legitimate hosts to the list if you're hit by an IP spoofing attack.

anav · Tue Jun 18, 2019 5:43 pm

None of these CVE-s are noted in the MT Security Blog and thus they are not real!

On the other hand Rich1 is not a Trump kinda guy and thus the concerns are probably on the up and up.
Is the thinking that its not MT config that is vulnerable but the linux kernel and thus not their problem????

Just to confirm, evoking the simple one liner rule will have no detrimental affects on 'normal' home traffic????
/ip firewall filter add action=drop chain=input protocol=tcp tcp-flags=syn tcp-mss=0-500

Yes, I do have some ports forwarded but not in the 0-500 range

kobuki · Tue Jun 18, 2019 5:51 pm

None of these CVE-s are noted in the MT Security Blog and thus they are not real!

Let's hope they have taken note and will issue an official comment and a patch. It's already in upstream.

Yes, I do have some ports forwarded but not in the 0-500 range

The TCP MSS is a TCP/IP specific parameter, unrelated to port numbers. It should not affect normal traffic at all. Maybe older modem-based services can be affected.

msatter · Tue Jun 18, 2019 6:07 pm

Chain input is a good step if you look at Mikrotik awn kernel. Also there are forwards and not all linux systems are already updated for this. Having also a main filter in the RAW looking at traffic coming in through the WAN is wise.

squeeze · Thu Jun 20, 2019 2:09 pm

https://isc.sans.edu/forums/diary/What+ ... nic/25046/

You are vulnerable if you are using a current Linux system, have selective acknowledgments enabled (a common default) and are using a network card with TCP Segment Offload (again, a common default in modern servers). A patch has been made available. Alternatively, you can disable SACK.

So, what is the state of TCP Segment Offload on Mikrotik network devices? Can we see the setting via RouterOS? Can the setting be changed?

Is a RAW rule like this sufficient? It drops any initial TCP packet advertising below 536 TCP MSS as per RFC 879 (untested):

/ip firewall raw add action=drop chain=prerouting protocol=tcp tcp-mss=0-535 tcp-flags=syn log=no log-prefix="SACK"
comment="SACK Panic: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479"

Thu Jun 20, 2019 2:54 pm

All issues fixed, versions coming soon:
https://blog.mikrotik.com/security/cve- ... 11479.html

anav · Thu Jun 20, 2019 4:58 pm

I do not see any particular rule, similar to the ones posted in this thread, referenced in the blog (standard IPV4 or input chain traffic) that would specifically target the CVEs?
( I mean as an interim mod, until new vers' are out).

fflo · Thu Jun 20, 2019 6:23 pm

As a sum up current recommended workaround bugfix is adding the following filters to the firewall until the patched packages are available?

/ip firewall raw add action=drop chain=prerouting protocol=tcp tcp-mss=0-535 tcp-flags=syn log=no log-prefix="SACK"
comment="SACK Panic: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479"
/ipv6 firewall raw add action=drop chain=prerouting protocol=tcp tcp-mss=0-535 tcp-flags=syn log=no log-prefix="SACK"
comment="SACK Panic: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479"

Hint: I guess the CVEs also apply to IPv6 SACK connections...

Sonnix · Thu Jun 20, 2019 6:57 pm

If I want to protect Linux hosts behind MikroTik that I can't patch at the moment would something like this work:

/ip firewall mangle add action=change-mss chain=forward in-interface=WAN new-mss=552 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1-255

Or is it better to use the proposed drop solution?

msatter · Thu Jun 20, 2019 11:44 pm

To me just dropping seems better to me. The fixes are on the way and my DECT phone blinked red today to indicate that needed attention. That was the RSS notification of this and the security log was containing new information.

laurinkus · Fri Jun 28, 2019 9:45 am

All issues fixed, versions coming soon:
https://blog.mikrotik.com/security/cve- ... 11479.html

How soon is coming soon?

Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Re: Linux vulnerabilities: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479

Who is online