[67] in bugtraq

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Julian Assange)
Fri Oct 21 16:21:12 1994

Date: Sat, 22 Oct 1994 01:50:59 +0000
From: Julian Assange <proff@suburbia.apana.org.au>
To: Justin Mason <jmason@iona.ie>
Cc: bugtraq@crimelab.com
In-Reply-To: <199410211050.LAA07173@destructor.iona.ie>


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

home help back first fref pref prev next nref lref last post