From owner-freebsd-audit Mon Nov 29 16: 1: 3 1999 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B816415570; Mon, 29 Nov 1999 15:58:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9B25F1CD623; Mon, 29 Nov 1999 15:58:47 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 15:58:47 -0800 (PST) From: Kris Kennaway To: Matthew Dillon Cc: Dan Moschuk , audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <199911292239.OAA11977@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Matthew Dillon wrote: > :> to increment when I look at 'ps' and 'jobs -l' output just as a > :> double check, and I'm sure other people do to. > : > :The big thing which randomized pids gives you is protection against > :tempfile guessing (e.g. /tmp/foo). We can't fix all of those bugs > :because they exist in a lot of third party code, including code without > :source. > : > :Kris > > Not really. Example: fork/exec an suid program. You now know what > the pid is (the return valud of the fork). There is no need to guess, > and a randomized pid won't help you. In fact, you can TSTP the program > relatively easily since you are probably still the controlling terminal. > You can effectively exploit the window even without TSTPing or STOPing > the program. You misunderstand the attack. In this case I'm the attacker, trying to defeat a child of a process which isn't mine. An example of this exploit in current FreeBSD is a temp file which is created during a parallel make world (I haven't gone back and figured out what). It makes a temp file called /tmp/something without checking for prior existance of the file. As the attacker, I can exploit this by looking at the current value of maxpid, and spawning say 500 links in /tmp with the correct name, pointing to /etc/passwd. Along comes Mr. linker (or whatever), creates the temporary file and lands in the 'minefield', follows my link, and actually creates it over the top of /etc/passwd. Boom. As you noted, this only reduces to a race condition when you randomize the PID, but it's at least a lot harder to exploit. We can fix this one in FreeBSD, but third party code is still just as trivial to exploit. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message