Date: Sun, 9 May 1999 06:48:37 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: sthaug@nethelp.no, Don.Lewis@tsc.tdk.com Cc: wes@softweyr.com, toasty@HOME.DRAGONDATA.COM, security@FreeBSD.ORG Subject: Re: KKIS.05051999.003b Message-ID: <199905091348.GAA20785@salsa.gv.tsc.tdk.com> In-Reply-To: sthaug@nethelp.no "Re: KKIS.05051999.003b" (May 9, 3:13pm)
next in thread | raw e-mail | index | archive | help
On May 9, 3:13pm, sthaug@nethelp.no wrote: } Subject: Re: KKIS.05051999.003b } > } - The client is asking for messages with zero iov's, and length 0. To } > } me, this means it shouldn't receive *anything* (file descriptors or } > } otherwise). But the program included below, slightly modified from the } > } client() routine, receives one message of length zero. The same thing } > } happens on for instance NetBSD 1.4-BETA or NetBSD 1.3.2. Does this mean } > } the semantics of receiving zero length messages aren't sufficiently } > } well defined? } > } > I believe the length refers to the length of any data that might } > accompany the descriptors. It should be OK to specify a length of 0. } > Even if the server was sending data in its reply, I believe it would } > not be an error to specify a zero length buffer. The data would just } > be truncated to fit the buffer size. } } Okay, but why should the *standalone* version of the client receive any } message at all (which it does: a zero length message) when there's no } sender involved at all? Darned if I know. Maybe it is because neither a data buffer or a control buffer is specified in your modified version. If you modify your example code to loop on recvmsg(), you'll find that recvmsg() will return 0 as many times as you want. FLASH! Now this is really wierd. The original exploit code doesn't show any signs leaking descriptors on one of our 3.1-stable machines, but /tmp (where the sockets are created) is mfs. If I change PATH and PATH_TMP so that they point to /var/tmp, sendmsg() fails with with ECONNREFUSED after the first iteration and descriptors are leaked. I might believe that descriptors could be leaked if sendmsg() fails this way, but why would sendmsg() fail if the sockets live in a ufs filesystem but not if the sockets live in a mfs filesystem? 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?199905091348.GAA20785>