bugtraq - Re: gzip TOCTOU file-permissions vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20050412114700.GA10763@box79162.elkhouse.de>
Date: Tue, 12 Apr 2005 13:47:01 +0200
From: Martin Pitt <martin.pitt@...onical.com>
To: Imran Ghory <imranghory@...il.com>
Cc: bugtraq@...urityfocus.com, 303927@...s.debian.org
Subject: Re: gzip TOCTOU file-permissions vulnerability

Hi Imran!

Imran Ghory [2005-04-04 20:57 +0100]:
> Vulnerable software
> ====================
> 
> gzip 1.2.4 and 1.3.3 and previous versions running on unix.
> 
> Vulnerability
> ==============
> 
> If a malicious local user has write access to a directory in which a
> target user is using gzip to extract or compress a file to then a
> TOCTOU bug can be exploited to change the permission of any file
> belonging to that user.
> 
> On decompressing gzip copies the permissions from the compressed
> gzip file to the uncompressed file. However there is a gap between the
> uncompressed file being written (and it's file handler being close)
> and the permissions of the file being changed.
> 
> During this gap a malicious user can remove the decompressed file and
> replace it with a hard-link to another file belonging to the user.
> gzip will then change the permissions on the  hard-linked file to be
> the same as that of the gzip file.

I tried this with gzip 1.3.5 and cannot reproduce this; when
gunzip'ing a file, the output file is _always_ created with 0600
permissions first, and chmod'ed to the original permission after
decompression finished. This matches perfectly to the source code in
gzip.c: treat_file() first calls create_outfile(), which does:

        /* Make sure that ofname is not an existing file */
        if (check_ofname() != OK) {
            close(ifd);
            return ERROR;
        }
        /* Create the output file */
        remove_ofname = 1;
        ofd = OPEN(ofname, flags, RW_USER);
        if (ofd == -1) {
            progerror(ofname);
            close(ifd);
            return ERROR;
        }

and looks very reasonable (RW_USER equals to 0600); then the
decompression takes place, and afterwards treat_file() calls
copy_stat() to chmod the output file.

This code is the same for version 1.3.2.

Of course the file can be removed by other users after gunzip has
finished, but that is not a gzip bug, but the result of the really
dumb idea to have a group/world-writeable directory without the sticky
bit.

Maybe I understood you wrong, could you please give a small test case
which describes the vulnerability exactly?

Thanks!

Martin
-- 
Martin Pitt               http://www.piware.de
Ubuntu Developer    http://www.ubuntulinux.org
Debian Developer         http://www.debian.org

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)