Project

General

Profile

Actions

Bug #15042

closed

Potential TCP connection denial of service attack from spoofed RST packets processed by PF

Added by Jim Pingle 7 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Category:
Rules / NAT
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09.1
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

There is a report (attached) that claims that a third party attacker can send TCP RST packets with a spoofed source and arbitrary sequence numbers for a wide range of ports and PF will remove a NAT state matching the src/dst without validating the sequence number matches the window of an ongoing connection.

The report doesn't make it clear if this is a new issue (or even which version of pfSense was tested), but if it's legitimate it almost certainly affects PF upstream as well.

Kristof said he'd take a look at the code there and see if he could find any issues.


Files

Actions #1

Updated by Kristof Provost 7 months ago

(Copy of what I just sent to )

Netgate received a report that there’s an issue with pf’s sequence number validation, specifically for forged RST packets. That results in fairy easy denial of service attacks (given that the attacker only has to work out the IP addresses and ports involved, not the sequence number).

My initial tests seem to confirm that this is indeed the case.

The attached pdf describes a scenario with NAT, but the issue manifests without NAT as well (see attached test case).

My current understanding is that it may be in part due to this: https://cgit.freebsd.org/src/tree/sys/netpfil/pf/pf.c#n5335
It’s not quite clear to me what that if block tries to accomplish.

Another factor is the incorrect check in https://cgit.freebsd.org/src/tree/sys/netpfil/pf/pf.c#n5371

Specifically, (pd->flags & PFDESC_IP_REAS) == 0) is currently always true (at least on IPv4), and is not a relevant check. It appears to cause the preceding checks to incorrectly pass, leading to an incorrect acceptance of the packet, and thus the DoS.

That’s also one distinction between us and OpenBSD’s version of this code. That is likely the reason I couldn’t reproduce this on OpenBSD.

The attached patch should be the fix we need.

Actions #2

Updated by Jim Pingle 7 months ago

  • Target version changed from 2.8.0 to 2.7.2
  • Plus Target Version changed from 24.03 to 23.09.1
Actions #3

Updated by Jim Pingle 7 months ago

  • Subject changed from Potential TCP NAT connection DoS from spoofed TCP RST packets to Potential TCP connection denial of service attack from spoofed RST packets processed by PF

Updating subject. This is not specific to NAT.

Actions #4

Updated by Jim Pingle 7 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Kristof pushed a fix for this to the Plus 23.09.1 and CE 2.7.2 branches.

Actions #5

Updated by Jim Pingle 7 months ago

  • Status changed from Feedback to Resolved

The behavior seems to be correct on current snapshots. On snapshots before the fix it would fall into time_wait every time I ran the attack script against the connection. On snapshots after the fix it appears to properly ignore the spoofed packets.

Actions #6

Updated by Jim Pingle 7 months ago

  • File deleted (Remote DoS Attack over Networks NATed with pfSense.pdf)
Actions #7

Updated by Jim Pingle 7 months ago

  • Private changed from Yes to No

This has been announced by FreeBSD as FreeBSD-SA-23:17.pf so the details are no longer private.

Actions

Also available in: Atom PDF