Re: access() is a security hole?
From: Ricardo Anguiano (firstname.lastname@example.org)
- Next message: Mike Silbersack: "Re: Sniffer nic"
- Previous message: David Schultz: "Re: access() is a security hole?"
- In reply to: The Anarcat: "access() is a security hole?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: The Anarcat <email@example.com> From: Ricardo Anguiano <firstname.lastname@example.org> Date: 10 Oct 2002 15:08:21 -0700
The Anarcat <email@example.com> writes:
> The access(2) manpage mentions an obscure security hole in
> access(2). How so?
> 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
-- Ricardo Anguiano CodeSourcery, LLC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message