Bugtraq mailing list archives
Re: access(2)--a security hole?
From: jmc () gnu ai mit edu (jmc () gnu ai mit edu)
Date: Fri, 21 Oct 1994 09:34:36 -0400 (EDT)
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. the actual syscall is executed in /sys/kern/vfs_syscalls.c, but i cant see why this is a hole. can you enlighten me?
access(2) is a security hole because the information it returns you is what was true, not was is currently true. This has bitten a lot of programs xterm being one that comes to mind. BAsically using access to check file perms of any sort is just asking for trouble since between the time access returns and the next line of your code, those permissions and/or the file itself may have changed. Basically, access should never be used in any setuid program for any purpose really. As a matter of fact, I'm not real fond of it for any use since it's unreliable at best and leads people to beleive something is true now that was only true once for a possible short period of time. James
Current thread:
- Fingerd Summary, (continued)
- Fingerd Summary Adam Shostack (Oct 20)
- Re: Fingerd Summary Stephen Gildea (Oct 21)
- Re: Fingerd Summary Adam Shostack (Oct 21)
- Re: Fingerd Summary KevinTX (Oct 21)
- access(2)--a security hole? Jonathan M. Bresler (Oct 20)
- Re: access(2)--a security hole? Justin Mason (Oct 21)
- Re: access(2)--a security hole? Dave Goldberg (Oct 21)
- Re: access(2)--a security hole? Karl Strickland (Oct 21)
- Re: access(2)--a security hole? Julian Assange (Oct 21)
- Re: access(2)--a security hole? John DiMarco (Oct 21)
- Re: access(2)--a security hole? jmc () gnu ai mit edu (Oct 21)
- adjunct *Hobbit* (Oct 20)