Date: Wed, 26 Jan 2000 18:06:53 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Merged patches Message-ID: <200001270206.SAA75635@gndrsh.dnsmgr.net> In-Reply-To: <200001270055.QAA02295@salsa.gv.tsc.tdk.com> from Don Lewis at "Jan 26, 2000 04:55:51 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
... > } Reserved means we should not be putting in hard code that effects how > } they behave, IMNSO. > > 255.255.255.255 is also defined as a broadcast address on the local network. > There's already code in the kernel that treats that in a special way. In > particular, if we send a TCP RST to this address, it will probably get turned > into a MAC level broadcast and get forwarded all over the local network, > though it wouldn't be forwarded by any routers. > > BTW, there already is code that treats class E addresses specially in > in_canforward(), which gets called from the packet routing code to > block the forwarding of packets in the address range, and also by the > ICMP code to block replies to this address range. Yes, I know, as I have had to rip it out in every ``experimental'' network project I have done. If I recall correctly that was done with the multicast intergration, and it was wrong, these are not defined to be multicast addresses by any standard, but the Deering multicast code treated them as such. > > } Your going to have to do the short and simple answer covers to cover > } the other parts of this space anyway, so you might as well only do it > } one place and not create what may be a headache for someone else. > > I don't think that the rest of this address space will be as much of > a problem. They stack might emit a RST packet with a destination address > in this range, but it won't go anywhere except maybe to the default router. And with the correct userland policy put in place via ipfw or ipfilter they won't even get that far. ... > > There is also the problem of source addresses that are broadcast addresses > on local networks. This shouldn't be remotely exploitable if you have > anti-spoofing filter rules on the router between the local network and > any untrusted networks. It might be a good idea to fix this as well at > some point, but this is harder to fix. More things that belong in firewall rules, not in the kernel. You going to complicate the code beyond comprehension and for little to no gain. > > Hey, don't we have a knob to control the forwarding of directed broadcasts? > I just looked and didn't see anything obvious. I think your thinking about net.inet.icmp.bmcastecho, I don't know of a directed broadcast forwarding knob on freebsd :-(. We deal with that issue with yet more ipfw policy. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001270206.SAA75635>