Re: access(2)--a security hole?

[proff () suburbia apana org au (Julian Assange)]

Access(2) is inhern

On Fri, 21 Oct 1994, Justin Mason wrote:

> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> > the FreeBSD man page for access(2) includes a section titled "CAVEAT" 
> > which says that "Access() is a potential security hole and should never 
> > be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.


On Fri, 21 Oct 1994, Justin Mason wrote:

> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> > the FreeBSD man page for access(2) includes a section titled "CAVEAT" 
> > which says that "Access() is a potential security hole and should never 
> > be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.


On Fri, 21 Oct 1994, Justin Mason wrote:

> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> > the FreeBSD man page for access(2) includes a section titled "CAVEAT" 
> > which says that "Access() is a potential security hole and should never 
> > be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.


On Fri, 21 Oct 1994, Justin Mason wrote:

> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> > the FreeBSD man page for access(2) includes a section titled "CAVEAT" 
> > which says that "Access() is a potential security hole and should never 
> > be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.

Acess(2)/(3) is inherently insecure because its argument is a file-name 
not
a file descriptor, meaning its vulnerable to race conditions, which mean 
that a link or file with different permissions could be implanted over 
the file that access passed.

Proff