Date: Mon, 31 Aug 1998 09:49:32 -0600 From: "Aaron D. Gifford" <agifford@infowest.com> To: security@FreeBSD.ORG Subject: Re: FreeBSD's RST validation Message-ID: <35EAC60C.1E2387BC@infowest.com> References: <19980830172141.G1186@ethereal.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Tristan Horn <tristan+-eyixqg@ETHEREAL.NET> wrote: > > RFC 793, pages 36-39 (chapter 3.5) describes closing connections with > TCP. Page 37 is of particular interest: > > Reset Processing > > In all states except SYN-SENT, all reset (RST) segments are validated > by checking their SEQ-fields. A reset is valid if its sequence number > is in the window. In the SYN-SENT state (a RST received in response > to an initial SYN), the RST is acceptable if the ACK field > acknowledges the SYN. > > Unfortunately, FreeBSD (2.2.5, 2.2.6, 2.2.7, 3.0) does not appear to > validate RST segments to this extent. In other words, only the packets' > IP/port pairs are checked. > > In my limited testing (oddly enough, not many people would consent to > DoS), Solaris, OSF/1, Linux and Windows 98 appear to conform to RFC 793 > in this regard. I have not yet been able to check NetBSD, OpenBSD, BSDI, > etc. > > This problem gets worse when you bring it to multi-user FreeBSD boxes > where netstat, systat -net, lsof (if improperly configured) and the like > can be used to get all IP/port pairs in use. I suggest (especially to > BEST) that these be chmod g-s or o-x'd until the problem is resolved. > > In cases where you only have the port number for one side of the > connection, exploiting the vulnerability is still fairly trivial. In > many (most?) cases, port 0 bind()s will start you off at port 1024 and > increment by one from there. Kudos to the OSes that already use random > or pseudorandom source ports... > > If the target is an IRC server or uses TCP wrappers, chances are that > you can telnet to it and you'll get a connection back to your ident port. > This will give you the high port. > > IRC in particular will probably be affected, due to the ease of getting > addresses and such. /stats L even used to give you the port numbers > for users, servers and listening sockets, but I believe this was fixed > in /hybrid a while back, and then +CS. /stats c should just be disabled > for non-opers since it lets people find the port # for autoconnects. > > SSH and similar secure sessions are in great danger because ports are > manually bound to, starting at 1023 and decrementing from there. > > BSD exploit code is attached (thanks to those who made land and ported > it!). Note that 'dstaddr' is where the RST packet is actually sent, so > it must be the address of a buggy machine. > > This (like /many/ other attacks) would be much less of a concern if more > people did ingress filtering. > > TS4 rocks! > > Tris <<exploit code attachment snipped>> <<pgp sig attachment snipped>> After seeing the above post to BUGTRAQ, I'm now wondering, what's the status of a fix? I didn't bother testing the exploit against my 2.2.7-STABLE (as of the end of July) system -- perhaps I should. Is it already fixed in in STABLE? Curious, Aaron out. -- "E, not a minor, Aaron, I'm a tone!" 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?35EAC60C.1E2387BC>