Re: Temp file attack auditing
On Thu, Nov 23, 2000 at 07:40:45PM -0400, Peter Cordes wrote:
> On Thu, Nov 23, 2000 at 05:50:06PM -0500, Daniel Burrows wrote:
> > On Thu, Nov 23, 2000 at 06:35:54PM -0400, Peter Cordes <peter@llama.nslug.ns.ca> was heard to say:
> > > > ghostscript uses temporary files to do some of its work. Unfortunately
> > > > the method used to create those files wasn't secure: mktemp was used
> > > > to create a name for a temporary file, but the file was not opened
> > > > safely.
> > > There seems to be a lot of this going on. Is it possible to modify glibc
> > > so that it flags dangerous actions with stuff in /tmp?
To be a bit pedantic, one can argue that only checking in glibc calls
risks missing problems - programs aren't compelled to go through
glibc's wrappers. Personally I compile my own kernel and not my own glibc,
so I prefer a kernel patch anyway.
> > When I link aptitude, I get a warning about "mktemp is insecure and
> > should not be used".
> > So I think something like this is already done somewhere.
>
> Yeah, that's at link time. gcc (or ld I guess) warns about gets(), too.
Hmm, since when did Debian ld get BSD-like linker warnings?
> I was thinking a runtime check would be useful, since then you could actually
> check whether the argument was a private directory or a publicly-writable
> one like /tmp, and be fairly sure you weren't seeing false alarms.
I use a kernel patch; after some refinement I got it to the point where it
can accurately identify unsafe file accesses.
http://members.nbci.com/colin_phipps/cph4.diff.txt (against kernel v2.2.17ish)
It errs on the side of not returning false positives; it logs to syslog
any file open(2) such that:
- it's in a world writable directory
- O_EXCL not specified
- file doesn't exist.
It's crude but turns up a lot of problems. Don't be surprised to find your
syslog busier if you try it, some programs are very bad about temp
files :-( (cvs is a bad culprit for instance).
--
Colin Phipps http://www.netcraft.com/
Reply to: