Date: Sun, 30 Aug 1998 22:35:30 -0400 From: Mike Tancsa <mike@sentex.net> To: security@FreeBSD.ORG Cc: questions@FreeBSD.ORG Subject: FreeBSD's RST validation (security question) Message-ID: <3.0.5.32.19980830223530.00f7a710@sentex.net>
next in thread | raw e-mail | index | archive | help
Just wondering if this latest bugtraq post has been addressed yet ? ---Mike >Approved-By: aleph1@DFW.NET >X-Mailer: Mutt 0.92.8i >Date: Sun, 30 Aug 1998 17:21:41 -0700 >Reply-To: Tristan Horn <tristan+-eyixqg@ETHEREAL.NET> >Sender: Bugtraq List <BUGTRAQ@netspace.org> >From: Tristan Horn <tristan+-eyixqg@ETHEREAL.NET> >Subject: FreeBSD's RST validation >To: BUGTRAQ@netspace.org > >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 > > > > > ********************************************************************** Mike Tancsa, Network Admin * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 01.519.651.3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.19980830223530.00f7a710>