Date: Fri, 23 Aug 2024 09:09:06 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 280701] FreeBSD-SA-24:05 fix breaks ICMP/ICMP6 states handling in pf firewall (ping, traceroute) Message-ID: <bug-280701-7501-NkXJGYYuiX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-280701-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-280701-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280701 --- 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.=20 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 g= uess 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 I= CMP 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.=20 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-280701-7501-NkXJGYYuiX>