[Bug 280701] FreeBSD-SA-24:05 fix breaks ICMP/ICMP6 states handling in pf firewall (ping, traceroute)

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 23 Aug 2024 09:09:06 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701

--- Comment #40 from doktornotor <doktornotor@mailinator.com> ---
Ok, so... let's recap this:

What original SA deals with - let me quote: "When pf is configured
to allow ND and block incoming Echo Requests, a crafted Echo Request packet
after a Neighbor Solicitation (NS) can trigger an Echo Reply."

This is "fixed" by a series of patches which cause the regression described
here, among others. 

Even after fixing the regression by another series of patches, people still
report that this caused yet more regressions, which directly match the area
touched by the original "issue" described in the SA. That is, breaks ND/NS (see
Comment #31 and following).

Additionally, people report that ONLY reverting all the patches to the state
before this "pressing" "security" issue of responding to ping - unnoticed by
anyone from 2009 at least, let alone exploited (for what exactly?) - gets
things back to working state without regressions.

The response here - downstream issue, lets close it.

Between the breakage caused here and responding to pings, it's everyone's guess
what users prefer. The original "security" "issue" has caused zero problems for
15+ years. Something's not responding to pings - yeah, there's a box with a
firewall in place blocking ping. If there was no computer with given address
connected, the evil attacker crafting the packets as per the SA would get ICMP
Destination Unreachable (ICMP Type 3) with one of the codes (such as 0 - net
unreachable, 1 - host unreachable ... etc). Blocking pings actually confirms
the computer is there, up and running. The only thing blocking responses to
ping does - make basic networking diagnostics / troubleshooting a PITA.

How's this whole thing a security issue deserving an SA and urgent patching
causing the above regressions which are impacting real network operation and
many users, goes beyond me, sorry. 

Once upon a time, common sense was in used, as documented by
http://www.faqs.org/rfcs/rfc1122.html - 3.2.2.6. Back to the drawing board.

Sigh. Have a nice day.

-- 
You are receiving this mail because:
You are the assignee for the bug.