CVE-2018-6922 (FreeBSD crash due to TCP fragment reassembly vulnerability)

[mfonkr]

I've been experiencing multiple crashes of my Netgate firewall, running FreeBSD 11.1-RELEASE-p10. I have indications from logs that the crashes are due to maliciously formed Telnet sessions from known bad Internet actors, and strongly suspect this vulnerability is the culprit. I sure hope the folks at Netgate/pfSense will integrate a FreeBSD update as soon as it's available ... this vulnerability is more than a nuisance to any FreeBSD device exposed to the Internet!

[jimp]

It's on the way.

https://www.netgate.com/docs/pfsense/releases/2-4-4-new-features-and-changes.html#security

[johnpoz]

@mfonkr said in CVE-2018-6922 (FreeBSD crash due to TCP fragment reassembly vulnerability):

maliciously formed Telnet sessions from known bad Internet actors,

So you have telnet open to the internet?

[mfonkr]

Thanks @jimp -- good to know. Hope it's sooner rather than later ...

[mfonkr]

Good Question @johnpoz

No, I don't have Telnet exposed. If I understand the vulnerability correctly, it doesn't matter what ports are exposed because the frame won't be dropped until it's reassembled - which doesn't happen before the crash. (If I have that wrong, please correct me.)

From the CVE, "An attacker who has the ability to send TCP traffic to a victim system can degrade the victim system's network performance and/or consume excessive CPU by exploiting the inefficiency [the algorithm used in FreeBSD v10/11] of TCP reassembly handling ... ". This CVE is the only explanation I could come up with for the frequent, recurring crashes of my Netgate appliance - all within the past week.

The logs I reviewed didn't clearly/directly indicate the reason for the crashes, though the first several crashes did show packets arriving from "Poor Reputation" (Snort) IP addresses, port 23. Regardless, my assumption about a Telnet session as the culprit appears spurious now. Crashes, after my original post, didn't have the same port-23-associated log entries just prior to the crash. Sadly I'm not skilled enough to dive deeper with equipment on hand. I never actually saw a CPU spike indication, but I'm guessing the 'degraded network performance/excessive CPU consumption' can occur without seeing indicators in real-time reporting information.

The crashes that have occurred required unplugging the firewall, then rebooting (with reset for >5-10 seconds after powering up) to get the appliance to boot normally. Unfortunately the crashes recurred - presumably after a scan found my FreeBSD machine operating again - typically 30-120 minutes later.

My interim solution: I put a non-FreeBSD router between the ISP and local network, so the FreeBSD firewall isn't directly exposed. Not my preferred long-term solution, but hopefully it holds till the OS update is available. No crashes in over 4 hours now, so it seems to be working (and also seems to validate a WAN-based cause for the crashes).

If ANYONE has a better/alternative explanation to my woes, I'm all ears!

[msf2000]

You must have at least 1 port open to the internet... The exploit mechanism requires an open TCP port.
https://www.kb.cert.org/vuls/id/962459

Workarounds would include blocking the attacker's IP (or country), or filtering/closing all open ports on your firewall WAN.

[mfonkr]

Thanks @msf2000 ... makes sense. And yes, I do have a few open TCP ports (not Telnet). They're important to functionality for me, so closing them would eliminate much of the utility I need. Unfortunately I don't have a specific, known attacker IP (else I'd be happy to block it). The firewall crashes and the associated log entry never gets saved (as the device crashes) - or at least I haven't found a log listing that's consistent across the crashes. If I missing something here, again, I'm all ears ...

Luckily, my temporary fix seems to be holding (9 hours and counting ...).

[Gertjan]

Hi,

Another fix could be : install the latest RC !
2.4.4 "final" will come out shortly afterwards.

[Wordo]

Is there a technical reason why there is no 2.4.3_2 release for this? Does it require to much resources for testing, QA etc.?

[Gertjan]

@wordo said in CVE-2018-6922 (FreeBSD crash due to TCP fragment reassembly vulnerability):

no 2.4.3_2 release for this

With 2.4.4 coming up in a couple of minutes (hours ?) ?
Remember that most firewalls have no ports open on WAN side, and if they have (I have), these are (is) UDP for VPN usage.
I do have a TCP port open, but my pfSense never restarted the last several years.

If this was a recurrent issue, like everybody complaining every day that their pfSense restarted, then yes, of course, an urgent intermediate upgrade would be thrown out.
Note that the FreeBSD kernel is the basement, or foundation of pfSense. Changing it is not something like "swapping files and reboot".

Btw : all this is my opinion, of course, just another pfSense user.

[Wordo]

Thanks! But running HAProxy or OpenVPN on 443/TCP for hotspot compatibility would be affected?
I also don't see such a high risk, but was wondering what the reason behind not pushing a new kernel to 2.4.3 release.

[Rico]

@mfonkr said in CVE-2018-6922 (FreeBSD crash due to TCP fragment reassembly vulnerability):

They're important to functionality for me, so closing them would eliminate much of the utility I need.

Maybe you could restrict the Source IP to only which must use these Services and block all others?

-Rico

[Derelict]

@wordo said in CVE-2018-6922 (FreeBSD crash due to TCP fragment reassembly vulnerability):

Thanks! But running HAProxy or OpenVPN on 443/TCP for hotspot compatibility would be affected?
I also don't see such a high risk, but was wondering what the reason behind not pushing a new kernel to 2.4.3 release.

Because the next release is 2.4.4. Users running 2.4.3 should update to that when it is available.