[61] in bugtraq
Re: access(2)--a security hole?
daemon@ATHENA.MIT.EDU (Jeremy Epstein -C2 PROJECT)
Fri Oct 21 10:33:09 1994
From: jepstein@cordant.com (Jeremy Epstein -C2 PROJECT)
To: bugtraq@crimelab.com
Date: Fri, 21 Oct 1994 08:46:23 -0400 (EDT)
In-Reply-To: <941021060028.554029@DOCKMASTER.NCSC.MIL> from "JJEpstein@DOCKMASTER.NCSC.MIL" at Oct 21, 94 02:00:00 am
[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
