Date: 10 Oct 2002 15:08:21 -0700 From: Ricardo Anguiano <anguiano@codesourcery.com> To: The Anarcat <anarcat@anarcat.ath.cx> Cc: freebsd-security@freebsd.org Subject: Re: access() is a security hole? Message-ID: <m3u1jux7ze.fsf@mordack.codesourcery.com> In-Reply-To: <20021008183227.GC309@lenny.anarcat.ath.cx> References: <20021008183227.GC309@lenny.anarcat.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
The Anarcat <anarcat@anarcat.ath.cx> writes:
> The access(2) manpage mentions an obscure security hole in
> access(2). How so?
>
> "
> CAVEAT
> Access() is a potential security hole and should never be used.
> "
>
> This seems to have been part of the manpage forever, or so to speak,
> so I really wonder what it's talking about. :)
In a nutshell, access(2) takes a string parameter, which indicates the
path to a file being checked. If after the user is found to have
sufficient permission, but before the program acts on this
information, the user my change the filesystem. By replacing the
original file with another file which that user does not have
access(2) to, a setuid program may be tricked into "using" a file on
behalf of the original user who does not have permission.
if (access("file")); // "file" changes after this line from myfile
// to myfile -> /var/spool/mail/boss
fd = open("file");
...
The problem is that there is no guarantee that the string "file"
refers to the same filesystem object for both system calls.
File descriptors don't suffer from this binding problem, but there is
no common file descriptor equivalent for access(2).
One way to get around this problem is to do the work of access(2)
using file descriptors instead:
fd = open("file");
fdstat(fd, buf); // fd still refers to same object even
// after filesystem change
if (access_check(buf))
...
HTH,
--
Ricardo Anguiano
CodeSourcery, LLC
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?m3u1jux7ze.fsf>