Bug #15042: Potential TCP connection denial of service attack from spoofed RST packets processed by PF - pfSense - pfSense bugtracker

Actions

Copy link

Bug #15042

closed

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

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

Status:

Resolved

Priority:

Normal

Assignee:

Kristof Provost

Category:

Rules / NAT

Target version:

2.7.2

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

Download all files

0001-pf-tests-test-that-we-validate-sequence-numbers-on-T.patch (6.8 KB) 0001-pf-tests-test-that-we-validate-sequence-numbers-on-T.patch		Kristof Provost, 11/29/2023 06:12 PM
0002-pf-remove-incorrect-fragmentation-check.patch (1.22 KB) 0002-pf-remove-incorrect-fragmentation-check.patch		Kristof Provost, 11/29/2023 06:12 PM

Actions

Copy link

Updated by Kristof Provost 12 months ago

(Copy of what I just sent to secteam@FreeBSD.org)

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

Copy link

Updated by Jim Pingle 12 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

Copy link

Updated by Jim Pingle 12 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

Copy link

Updated by Jim Pingle 12 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

Copy link

Updated by Jim Pingle 12 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

Copy link