Date: Wed, 26 Jan 2000 16:55:51 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, 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: <200001270055.QAA02295@salsa.gv.tsc.tdk.com> In-Reply-To: <200001261114.DAA74269@gndrsh.dnsmgr.net> References: <200001261114.DAA74269@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 26, 3:14am, "Rodney W. Grimes" wrote: } Subject: Re: Merged patches } > On Jan 25, 11:34am, "Rodney W. Grimes" wrote: } > } Subject: Re: Merged patches } > } > I found a bug in the patch: } > } > } > } > : #endif } > } > :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) } > } > :- goto drop; } > } > :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || } > } > :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || } > } > :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) } > } } > } And yet another bugger.... you just made it impossible for anyone } > } doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD } > } using TCP without hacking the kernel code. Please remove the } > } last check here. } > } > How about changing the last part to to } > ip->ip_src.s_addr == htonl(INADDR_BROADCAST) } > which is the subset of IN_EXPERIMENTAL that I was concerned about. } > } > Without this, someone will post yet another variant of this attack } > using a broadcast source address. } } The short and simple answer: } ipfw add deny ip from 240.0.0.0/4 to any } } The longer answer: } Manning is not very clear on Class E space, Technically 255.255.255.255 } is a class E address, and is part of ``a range left unspecified''. Putting } your patch above in would be ``specifing'' a behavior. But yet Manning } later says: } } Note: No addresses are allowed with the four highest-order bits } set to 1-1-1-1. These addresses, called "classE", are reserved. } } 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. } 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. } Also don't some strange clients like DHCP use this as a source address } during their startup phase? No, they use 0.0.0.0 as their source address and 255.255.255.255 as their destination address. They also don't use TCP. 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. Hey, don't we have a knob to control the forwarding of directed broadcasts? I just looked and didn't see anything obvious. 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?200001270055.QAA02295>