From owner-freebsd-security Sat May 8 21:22: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 5596714F17 for ; Sat, 8 May 1999 21:21:55 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id WAA18098; Sat, 8 May 1999 22:21:44 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <37350D57.C21154@softweyr.com> Date: Sat, 08 May 1999 22:21:43 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis Cc: Kevin Day , security@FreeBSD.ORG Subject: Re: KKIS.05051999.003b References: <199905090326.UAA19750@salsa.gv.tsc.tdk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Lewis wrote: > > On May 7, 11:34pm, Wes Peters wrote: > } Subject: Re: KKIS.05051999.003b > } Don Lewis wrote: > } > > } > On May 6, 2:10pm, Kevin Day wrote: > } > } > } > } Here's my testing so far: > } > } > } > } 2.2.2 - Vulnerable > } > } 2.2.6 - Vulnerable > } > } 2.2.8 - Vulnerable > } > } 3.1-RELEASE - Ran 15 minutes, no crash. > } > } Let it keep running. It will (apparently) eventually exhaust all > } available file handles in an unrecoverable manner. 3.1-R is better, > } but not invulnerable. > > I don't see any obvious descriptor leaks, but the fact that FreeBSD < 3.1 > panics (probably in unp_gc(), which Matt fixed) indicates that I'm missing > something. The exploit code should not result in any calls to unp_gc(), > because the client receives all the descriptors that are sent by the server. Actually it doesn't. If you look up the first message I posted on this subject, I listed the error messages it produces, many of which indicated the client didn't get a descriptor from the server IIRC. Maybe that's how the descriptors are being lost; they've been sent on a UNIX domain socket and so have to remain open, have been closed by the server, working around it's limits, and have not been read by the client? > This should result in unp_rights being 0 except when the descriptor is > in flight. If unp_rights is 0 when the socket is closed, unp_gc() should not > be called. unp_gc() should only be called if the client closes socket before > receiving the descriptor. > > Maybe a third process occasionally get scheduled while the exploit code > has the descriptor in flight and causes unp_gc() to get executed. If so, > then the exploit shouldn't cause a problem in single user mode. I haven't had time to research this any further, I spent today chasing a VERY engergetic toddler. I'm too old for this. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message