Re: [PATCH] Fix system() behaviour when parameter is NULL

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Thu, 28 Aug 2008 15:13:55 -0400 (EDT)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> >> "access() is a potential security hole and should never be used."
> > Actually, the statement is wrong...  Rather, it needs a few more
> > qualifiers.  One of the original purposes of access() was to let
> > setuid() programs check if the real uid had certain privileges on
> > the file.  That doesn't work properly because of race condition
> > attacks.
> 
> Well...strictly speaking, it works, but opens up a classic test-vs-use
> race if you then proceed to count on the result to mean that it's safe
> to use the pathname you tested.  (Except for cases where all the
> directories leading to the object are unwritable to all attackers
> inside the threat model, which is the case rarely enough that the
> possibility can usually be ignored.)

I think this is what I said.  The usual buzzword for this specific kind
of attack is TOCTTOU -- "time of check to time of use".
> 
> This is rather more complicated than someone needing the manpage is
> likely to grok; the warning that's there is a workable approximation
> for the people who need warning.

Maybe.
> 
> > However, if you're not looking at that issue, it's a perfectly fine
> > system call.
> 
> Yes.  However, is it the right one here?  If system()'s caller is
> set-id, I'm not convinced it will give the answer we want if the ruid
> and euid have different access rights on _PATH_BSHELL.

A different question entirely, and you may be right -- I was simply
answer the question about whether access() is a security hole per se.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb