From owner-freebsd-security Mon Aug 31 08:50:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07501 for freebsd-security-outgoing; Mon, 31 Aug 1998 08:50:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA07496 for ; Mon, 31 Aug 1998 08:50:48 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from infowest.com (eq.net [207.49.60.250]) by infowest.com (8.8.8/8.8.8) with ESMTP id JAA00665 for ; Mon, 31 Aug 1998 09:49:43 -0600 (MDT) Message-ID: <35EAC60C.1E2387BC@infowest.com> Date: Mon, 31 Aug 1998 09:49:32 -0600 From: "Aaron D. Gifford" X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.7-STABLE i386) MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: FreeBSD's RST validation References: <19980830172141.G1186@ethereal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tristan Horn 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 <> <> 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