Re: access() is a security hole?

From: Ricardo Anguiano (anguiano@codesourcery.com)
Date: 10/11/02


To: The Anarcat <anarcat@anarcat.ath.cx>
From: Ricardo Anguiano <anguiano@codesourcery.com>
Date: 10 Oct 2002 15:08:21 -0700

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


Relevant Pages

  • Re: access() is a security hole?
    ... > CAVEAT ... > Accessis a potential security hole and should never be used. ... > This seems to have been part of the manpage forever, or so to speak, ...
    (FreeBSD-Security)
  • Re: access() is a security hole?
    ... >> CAVEAT ... >> Accessis a potential security hole and should never be used. ... I'll try to come up with an update to the manpage. ...
    (FreeBSD-Security)
  • access() is a security hole?
    ... The accessmanpage mentions an obscure security hole in ... Accessis a potential security hole and should never be used. ... This seems to have been part of the manpage forever, or so to speak, ...
    (FreeBSD-Security)
  • Re: _cleanup() vs Linux fcloseall()
    ... I'd prefer to see a function that closed all file descriptors greater ... stdin/out/err but close everything else). ... indirectly by saying that fflushis used prior to closing the streams. ... According to fcntlmanpage from the netbsd, ...
    (freebsd-current)