[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Feb 2013 16:49:42 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: oss-security@...ts.openwall.com
cc: Matthias Weckbecker <mweckbecker@...e.de>, mjt@....msk.ru
Subject: Re: CVE# request: pigz creates temp file with insecure
permissions
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.
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)
- 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
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.
