[21521] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Tripwire temporary files

daemon@ATHENA.MIT.EDU (Jarno Huuskonen)
Mon Jul 16 01:03:53 2001

Date: Fri, 13 Jul 2001 08:08:37 +0300
From: Jarno Huuskonen <Jarno.Huuskonen@uku.fi>
To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
Cc: Charles Stevenson <core@ezlink.com>, Bugtraq <bugtraq@securityfocus.com>,
        Vuln-dev <vuln-dev@securityfocus.com>
Message-ID: <20010713080836.A161232@messi.uku.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200107130156.f6D1uhL75338@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Thu, Jul 12, 2001 at 06:56:42PM -0700

On Thu, Jul 12, Cy Schubert - ITSD Open Systems Group wrote:

> I don't know whether the commercial version (2.4) has this bug (haven't 
> installed it yet, though as the free version is probably based on the 
> commercial version, I suspect (guess) it might be.

I have reported the tempfile issue to tripwire back in January. I was
under the impression that (then upcoming 2.4) would have this fixed.  I
haven't checked if it fixes the bug, but AFAIK it has the TEMPDIRECTORY
config option so you can use 'safe' temp directory.

> And for Tripwire-2.3.1 the patch is:
> --- src/core/unix/unixfsservices.cpp.orig	Sat Feb 24 11:02:12 2001
> +++ src/core/unix/unixfsservices.cpp	Tue Jul 10 21:40:37 2001
> @@ -243,6 +243,7 @@
>  {
>      char* pchTempFileName;
>      char szTemplate[MAXPATHLEN];
> +    int fd;
>  
>  #ifdef _UNICODE
>      // convert template from wide character to multi-byte string
> @@ -253,13 +254,14 @@
>      strcpy( szTemplate, strName.c_str() );
>  #endif
>  
> -    // create temp filename
> -    pchTempFileName = mktemp( szTemplate );
> +    // create temp filename and check to see if mkstemp failed
> +   if ((fd = mkstemp( szTemplate )) == -1) {
> +     throw eFSServicesGeneric( strName );
> +   } else {
> +     close(fd);
> +   }
> +   pchTempFileName = szTemplate;
>  
> -    //check to see if mktemp failed
> -    if ( pchTempFileName == NULL || strlen(pchTempFileName) == 0) {
> -      throw eFSServicesGeneric( strName );
> -    }
>  
>      // change name so that it has the XXXXXX part filled in
>  #ifdef _UNICODE

If you look a little below you'll see a call to FileDelete(strName); So
first you create a file with mkstemp and then unlink it. And because
cFileArchive::OpenReadWrite(line 708) then opens the same file(name) without
O_EXCL there still is a race. So I don't think this is a sufficient fix.
You should make cFileArchive::OpenReadWrite use O_EXCL.
I have --> untested <-- patch (probably fails horribly ;-) for this:
http://www.uku.fi/~jhuuskon/Patches/tripwire-2.3.1-2-O_EXCL.patch

> We haven't had a chance to install the commercial version yet, however 
> if the commercial version is vulnerable (I've notified TripwireSecurity 
> of the possibility and I'm betting dollars to donuts that is might be) 
> a possible workaround would be to create a shared library with a 
> function named mktemp which would call mkstemp() as in the patches 
> above, then execute tripwire using LD_PRELOAD to load the mktemp 
> wrapper.

Back in january the binary tripwire 2.2.1 for linux was statically
compiled / linked. Can you use LD_PRELOAD with static executables ?

-Jarno

-- 
Jarno Huuskonen <Jarno.Huuskonen@uku.fi>

home help back first fref pref prev next nref lref last post