oss-security - Re: CVE# request: pigz creates temp file with insecure permissions

Follow @Openwall on Twitter for new release announcements and other news

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

Message-ID: <511F27F6.9040900@redhat.com>
Date: Fri, 15 Feb 2013 23:32:22 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: "Steven M. Christey" <coley@...re.org>,
        Matthias Weckbecker <mweckbecker@...e.de>, mjt@....msk.ru
Subject: Re: CVE# request: pigz creates temp file with insecure
 permissions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/15/2013 02:49 PM, Steven M. Christey wrote:
> 
> Kurt,
> 
> As Michael describes the issue: "When [pigz] finishes, it
> correctly applies original file permissions to the newly created
> file."
> 
> By changing the permissions of the file AFTER compression, pigz is 
> clearly trying to implement a security policy of "preserve the 
> permissions of the original file."  It is not properly obeying its
> own security policy because of the race condition, so this is a
> more clear argument for assigning a CVE than in the general case
> where a program's default policy may be "rely on the umask."
> 
> So, pigz should have a CVE.

Agreed, I read to quickly and sort of glossed over it.

> Going forward, maybe the guidelines could look something like:
> 
> - if the program tries to implement a security-relevant policy but 
> fails - assign CVE
> 
> - if the program has functionality that is clearly for secrecy, 
> e.g. gnupg - assign CVE (it should have a policy that preserves 
> secrecy)

So as a rule of thumb:

1) private encryption keys/certificates/tokens
2) non hashed passwords for sure

And less certain:

3) hashed passwords (/etc/shadow being readable = security vuln)
4) configuration data (of a sensitive nature?)
5) User data (e.g. email/web files?)

> - if the program's vendor explicitly states that the issue is a 
> vulnerability - assign CVE (this is stating an explicit security 
> policy)
> 
> - otherwise, if the program defaults to umask but does not have
> any inherent secrecy requirements or explicit policies, or if the
> vendor treats the issue as "hardening" but not a strict
> vulnerability - maybe no CVE

So just to be clear in the following situation:

1) we have a file "foo" with permissions of say 0640 (-rw-r-----.)
2) we have a umask that is less restrictive (e.g. 0007)
3) we run a program "bar" on file "foo" which creates an output of say
"baz"

ANY program that operates on fiz and creates the output baz with the
permissions of the umask (so 0660 or whatever) is not automatically
considered to have a security vulnerable, we would then need to apply
knowledge of the intent of the program/the data it handles.

> Your past suggestions for MUST/SHOULD language could be one
> mechanism for getting more clear about "security policy" in the
> future.

The benefit here would be projects/vendors could then state security
policy and we would have a more clear situation (it would fall under
your third point "if the program's vendor explicitly states that the
issue is a vulnerability - assign CVE (this is stating an explicit
security policy").

> - Steve


- -- 
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)

iQIcBAEBAgAGBQJRHyf1AAoJEBYNRVNeJnmTxF4P/0jjkPSEhqRSTQk7Q7Nqe0vV
VcHf8efCwlx7QahNpDrz86Jf5xmaDIxi5ogmZ34fBFos47LnIdedGzEE3q1bbkOD
6YDUXRWlEb66vJa4Ci7iSpxCfkGAKomAbfQi3lAJt8PnP+o9zhpQdVKZ3HJUXC31
SjzZAzzeF1Nmz70vLkYE+B9iqPd+VR2gzHhJG01b1VbId2HMwWZigozBSQj0tt6C
leNR/79533cZQcKmgCt4ABHHIsxyk2Kr8Gcqeha/QhIsC30A1cRK7P653SwX23fz
acUfBQyvY+XLs/jERhFm0PrQ3KVMqZgj8CphAQsEFRyKipqSLjFmLETmCVFb8vBF
GQiWJMSNjk++yvfk/8TrVDVcleK7FCc/pc6/42N73cO98g8g0m8WkVuLWSv1vhX1
YEZ0B8Z2IK865wlya96zQuI6Naeh2tupYiOEMDL7piL/ZEAIbZq3XooJd3R9C9ie
WffixWnijrroGm1zJyv+EQ+Tlr+k4v4V5QqZaYK7J+vORHZ9OLkrpSOpJdxx2mMO
rOISNQ+IhIr/23k+nbQJDuwAdVAQZRd07Tr6Rqvl6tkZr/B/keuYxayJ9bp/S2TY
99Muj9E6sXYmHFd3RUSdF3eM9wX+0wgo74T+BRbGEFjzcEtGaIXBdNtu6M9vd5iA
ae6bLkzCk/bnCbbiwnlX
=WsN8
-----END PGP SIGNATURE-----

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.