Bugtraq mailing list archives
Re: access(2)--a security hole?
From: jepstein () cordant com (Jeremy Epstein -C2 PROJECT)
Date: Fri, 21 Oct 1994 08:46:23 -0400 (EDT)
[Sorry, the first version of this didn't have the response.]
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." i looked into libc source and access is a typical system call--no real source at all, just enough assembler wrapper to generate a system call with the correct arguments. the assembler is generated when libc is compiled through defines and other macros--real slick.
I believe that the real risk isn't with the system call itself, but with using it incorrectly in programs (especially setuid programs). It gets used in some UNIX systems to determine whether you have enough access to spool a file (for example). However, because it is not indivisible from open, nor does it take account of symbolic links which may be created or changed, it's an easy way for a security flaw to creep in. For example, if lpr checks whether you have access to a file being queued (using the access() system call), but lpd fails to verify that the file is still what it was before (i.e., if it's a symbolic link it hasn't been changed, if it was a file when spooled it hasn't become a symbolic link), then you could get printouts of files you have no rights to. I believe that particular bug has been discussed on this list before; I don't know if it's been fixed in any of the popular implementations. --Jeremy Epstein jepstein () cordant com
Current thread:
- Re: access(2)--a security hole? Jeremy Epstein -C2 PROJECT (Oct 21)
- <Possible follow-ups>
- Re: access(2)--a security hole? Jeremy Epstein -C2 PROJECT (Oct 21)
- Re: access(2)--a security hole? der Mouse (Oct 21)
- Re: access(2)--a security hole? Steve Simmons (Oct 22)
- Re: access(2)--a security hole? Kayvan Sylvan (Oct 22)
- Re: access(2)--a security hole? Howie Kaye (Oct 22)
- Re: access(2)--a security hole? der Mouse (Oct 22)