From owner-freebsd-security  Sun May  9  6: 9:17 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 EBE8115036
	for <security@FreeBSD.ORG>; Sun,  9 May 1999 06:09:14 -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 GAA12139;
	Sun, 9 May 1999 06:08:52 -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 GAA16038;
	Sun, 9 May 1999 06:08:51 -0700 (PDT)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id GAA20692;
	Sun, 9 May 1999 06:08:50 -0700 (PDT)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199905091308.GAA20692@salsa.gv.tsc.tdk.com>
Date: Sun, 9 May 1999 06:08:49 -0700
In-Reply-To: sthaug@nethelp.no
       "Re: KKIS.05051999.003b" (May  9, 11:29am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: sthaug@nethelp.no, Don.Lewis@tsc.tdk.com
Subject: Re: KKIS.05051999.003b
Cc: wes@softweyr.com, toasty@HOME.DRAGONDATA.COM,
	security@FreeBSD.ORG
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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