Re: gzip TOCTOU file-permissions vulnerability

[Martin Pitt <martin.pitt () canonical com>]

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

Attachment: signature.asc
Description: Digital signature