oss-sec mailing list archives
Re: CVE# request: pigz creates temp file with insecure permissions
From: Kurt Seifried <kseifried () redhat com>
Date: Fri, 15 Feb 2013 23:32:22 -0700
-----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-----
Current thread:
- CVE# request: pigz creates temp file with insecure permissions Michael Tokarev (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Matthias Weckbecker (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Kurt Seifried (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Steven M. Christey (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Kurt Seifried (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Michael Tokarev (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Kurt Seifried (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Matthias Weckbecker (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Kurt Seifried (Feb 15)
- Re: CVE# request: pigz creates temp file with insecure permissions Jim Mellander (Feb 27)