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 16:49:42 -0500 (EST)
From: "Steven M. Christey" <>
cc: Matthias Weckbecker <>,
Subject: Re: CVE# request: pigz creates temp file with insecure


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.

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

- if the program's vendor explicitly states that the issue is a
   vulnerability - assign CVE (this is stating an explicit security

- 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

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

- Steve

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.