[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: