Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Feb 2013 23:32:22 -0700
From: Kurt Seifried <>
CC: "Steven M. Christey" <>,
        Matthias Weckbecker <>,
Subject: Re: CVE# request: pigz creates temp file with insecure

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

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

Version: GnuPG v1.4.13 (GNU/Linux)


Powered by blists - more mailing lists

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.