[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE# request: pigz creates temp file with insecure permissions
From:       Jim Mellander <jmellander () lbl ! gov>
Date:       2013-02-27 18:15:52
Message-ID: CADju=b4Ca_YVA=tG+bfjMYEK_BHgjMesEE+OEBeGwPfQcQ=08Q () mail ! gmail ! com
[Download RAW message or body]

This was reported to and corrected by the pigz maintainer on 7/26/12, per:

Jim Mellander <jmellander@lbl.gov>
7/26/12

to madler, pigz-announce-.
Hi:

I recently downloaded and tried pigz - thanks for the software - its
very useful for multicore systems, especially on the big iron that
NERSC runs.  However, there seems to be a security hole, relating to
permissions during compression.  The permissions of the .gz file being
created are less restrictive than the original file, which is
different than gzip, per the below:

using gzip:

# gzip -9 x &
[1] 17014
# ls -l x*
-rw-------. 1 root root 1217318912 Jul 26 12:34 x
-rw-------. 1 root root   63602688 Jul 26 12:47 x.gz
#


using pigz:

# pigz -9 x&
[1] 17017
# ls -l x*
-rw-------. 1 root root 1217318912 Jul 26 12:34 x
-rw-r--r--. 1 root root   75392287 Jul 26 12:48 x.gz
# pigz --version
pigz 2.2.4
#


the file contents are potentially exposed during compression due to
permissions, which is a potential security hole....

Hope this helps,

Jim Mellander
NERSC Cybersecurity
510-486-7204

On Fri, Feb 15, 2013 at 10:33 PM, Kurt Seifried <kseifried@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/15/2013 01:33 AM, Michael Tokarev wrote:
>> I think this one well deserves a CVE#.  I just submitted the
>> following bug #700608 to Debian BTS:
>>
>> When asked to compress a file with restricted permissions (like
>> mode 0600), the .gz file pigz creates while doing this has usual
>> mode derived from umask (like 0644).  If the file is large enough
>> (and why we would use pigz instead of gzip for small files), this
>> results in the original content being readable for everyone until
>> the compression finishes.
>>
>> Here's the deal:
>>
>> $ fallocate -l 1G foo $ chmod 0600 foo $ pigz foo & $ ls -l foo
>> foo.gz -rw------- 1 mjt mjt 1073741824 Feb 15 12:27 foo -rw-rw-r--
>> 1 mjt mjt     502516 Feb 15 12:27 foo.gz
>>
>> When it finishes, it correctly applies original file permissions to
>> the newly created file, but it is already waaay too late.
>>
>> Other one-file archivers (gzip, xz, bzip2, ...) usually create the
>> temp file with very strict permissions first, and change it to the
>> right perms only when done, so only the current user can read it.
>
> Apologies for my first misreading of this. Please use CVE-2013-0296
> for this issue.
>
>>
>> Thanks!
>>
>> /mjt
>>
>
>
> - --
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
>
> iQIcBAEBAgAGBQJRHyhPAAoJEBYNRVNeJnmT/58QANpX3fNSN/DV2k2h6/TMreid
> gnqYXxndMTo6D63+4jWkKyMb+XsJjNJ52jvN3wAYwKGVk7MtrDzKydDFn5qFMBJ0
> 4Ysp+cVsD5HE4QRc6cJPkBNaoKA6t+cj0fInu/hqkXMTAZpUDEPn9p4FUjB0OSrJ
> nOFz4PWbAPX8KItMNUmMCu/r2OnOQ7vhJDHk37GIXhEwvZE9Hf2m2mNtBfBHHrlw
> 7x8fO0lEmYi3aOhkvm+ka0U/YplmNWxWXjF0xoxzwQgEeJV+xSiCgk7Wk4YzYLTm
> i4TPI/RHvvuXgKs2mzHXE6qu5F0ADif0Vhl2iEasl8X3Zjeb6nZ7i6r+eTAMmsXf
> pJvDbC28PnPGSC+u9J4oibDbugu7FJXyYDWtDz6ylQTFDJZ6nXPKGfUUbq2i/7vn
> G84r/1LsrF8PxBFu8fFCD/+tZtyoCMU8qosfiTFHi4sgVF/4jGBVmICkyn6IE+3e
> VL/bcutjWd9gGg9S8MaAO+TDnEmaJbvluPlBandKNdZIV18e7bDed6fsGwXiyJ12
> XGIC5A9IgxioG4yFguwB1LutVaBMW80UxjMZQDOoeTOLWLS6dLqFuLbWz3DK0b3a
> aqh+tH1OvYNHgpu9UFDFFVvGCMziXL8k95dPb/8BbHF0YB4GGP9K0V77BEvRBJkC
> jAPHv+UOIAjW2xXDwTyK
> =OByZ
> -----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]