Date: Sat, 8 May 1999 20:26:05 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Wes Peters <wes@softweyr.com>, Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Kevin Day <toasty@HOME.DRAGONDATA.COM>, security@FreeBSD.ORG Subject: Re: KKIS.05051999.003b Message-ID: <199905090326.UAA19750@salsa.gv.tsc.tdk.com> In-Reply-To: Wes Peters <wes@softweyr.com> "Re: KKIS.05051999.003b" (May 7, 11:34pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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?199905090326.UAA19750>