From owner-freebsd-questions Sun Aug 30 19:32:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA08117 for freebsd-questions-outgoing; Sun, 30 Aug 1998 19:32:52 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from coal.sentex.ca (coal.sentex.ca [209.112.4.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA08112; Sun, 30 Aug 1998 19:32:48 -0700 (PDT) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by coal.sentex.ca (8.8.8/8.8.7) with SMTP id WAA07343; Sun, 30 Aug 1998 22:31:46 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <3.0.5.32.19980830223530.00f7a710@sentex.net> X-Sender: mdtancsa@sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 30 Aug 1998 22:35:30 -0400 To: security@FreeBSD.ORG From: Mike Tancsa Subject: FreeBSD's RST validation (security question) Cc: questions@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 >Sender: Bugtraq List >From: Tristan Horn >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