From owner-freebsd-security Sun May 9 5:40:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 30E4014E61 for ; Sun, 9 May 1999 05:40:36 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id FAA11974; Sun, 9 May 1999 05:40:30 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id FAA15973; Sun, 9 May 1999 05:40:29 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id FAA20619; Sun, 9 May 1999 05:40:27 -0700 (PDT) From: Don Lewis Message-Id: <199905091240.FAA20619@salsa.gv.tsc.tdk.com> Date: Sun, 9 May 1999 05:40:27 -0700 In-Reply-To: Wes Peters "Re: KKIS.05051999.003b" (May 8, 10:21pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Wes Peters , Don Lewis Subject: Re: KKIS.05051999.003b Cc: Kevin Day , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On May 8, 10:21pm, Wes Peters wrote: } Subject: Re: KKIS.05051999.003b } Don Lewis wrote: } > 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? I think all those messages are the result of running out of descriptors. If no more descriptors can be created, then socket will fail with ENFILE (23), and bind(), sendto(), and recvmsg() will fail with EBADF (9), and unlink() will fail with ENOENT (2). I'd have to study the code some more to work out the expected sequence of the errors assuming that no more descriptors could be created. The message containing the descriptor to be passed holds a reference to the descriptor, so it is permissible for the server to close the descriptor before the client receives the message. See unp_internalize() and unp_externalize(). BTW, how does this manage to work on the Alpha, where sizeof(int) != sizeof(pointer)? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message