Date: Sun, 9 May 1999 06:08:49 -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: <199905091308.GAA20692@salsa.gv.tsc.tdk.com> In-Reply-To: sthaug@nethelp.no "Re: KKIS.05051999.003b" (May 9, 11:29am)
next in thread | raw e-mail | index | archive | help
On May 9, 11:29am, sthaug@nethelp.no wrote: } Subject: Re: KKIS.05051999.003b } > 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. } } It happens in single user mode too. } } In general, this program leaks one file descriptor for each time round } the client/server loops - this is easy to see if you add some debugging } printout to falloc()/ffree() in sys/kern/kern_descrip.c. } } If you parametrize the client loop, ie. } } case 0: } for (n=0;n<rounds;n++) } client(); } } you'll find that it leaks N-1 file descriptors if the client loop is run } N times and the program is aborted with ^C. It's eminently reproducible. Hmn ... } Other interesting points about this program: } } - The client shouldn't receive anything at all, because it's listening } on a different socket (using PATH_TMP) than the server (using PATH) is } sending on. The client starts by doing a sendto() to send a message to the server at address PATH. The server receives this message using recvfrom(), which returns the source of the message (PATHTMP) in addr. When the server uses sendmsg() to return its response (with the embedded descriptor) to the client, it sends this message to the address that it received in the recvfrom(). } - If you remove the following part of the client() routine: } } if ( sendto( sockfd,&data,sizeof( data),0,(struct sockaddr *) &addr_s, } addr_s.sun_len) == -1) } printf( "client: sendto error %d\n",errno); } } there is no longer any leak. Right, because this is what prompts the server to wake up and send each descriptor to the client. Without this sendto(), the server waits forever in recvfrom(), and the client falls through to its recvmsg() call and hangs. } - 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. 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?199905091308.GAA20692>