[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 21 Sep 2012 12:18:18 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Michael Gilbert <mgilbert@...ian.org>
Subject: Re: Re: CVE request(?): gpg: improper file permssions
set when en/de-crypting files
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/21/2012 09:31 AM, Michael Gilbert wrote:
> On Fri, Sep 21, 2012 at 6:37 AM, Tomas Mraz wrote:
>> On Fri, 2012-09-21 at 12:20 +0200, Matthias Weckbecker wrote:
>>> Hello Steve, Kurt, Vitezslav, Tomas, vendors,
>>>
>>> we have recently been notified about a potential issue with
>>> gpg: When files are en/de-crypted the result is written
>>> world-readable by default. Short example (quote from [1]):
>>>
>>> # de-crypting % gpg sikrit.gpg % ll sikrit* -rw-r--r-- 1 gp
>>> users 12 Sep 17 09:41 sikrit -rw------- 1 gp users 480 Sep 17
>>> 09:40 sikrit.gpg # en-crypting % echo "my password" > sikrit %
>>> chmod go= sikrit % ll sikrit -rw------- 1 gp users 12 Sep 17
>>> 09:38 sikrit % gpg -e -r pfeifer sikrit % wipe sikrit % ll
>>> sikrit.gpg -rw-r--r-- 1 gp users 480 Sep 17 09:40 sikrit.gpg
>>>
>>> [1] https://bugzilla.novell.com/show_bug.cgi?id=780943
>>>
>>> Wouldn't one usually expect files that were previously
>>> encrypted to contain sensitive content (that's probably why
>>> content is encrypted at all)? And if so, shouldn't such files
>>> be only readable by certain users / group of users by default?
>>> Otherwise, a file that is e.g. decrypted in /tmp might leak
>>> due to the file permissions being too loose.
>>>
>>> I'm not quite sure whether to assign a CVE for this, so I
>>> thought I'd just add a question mark behind the subject and let
>>> the list (and Kurt) decide.
>>
>> I suppose the permissions respect the user's umask so I do not
>> think this is a real security issue in the gpg itself. Although
>> using the permissions of the original file when creating the
>> decrypted/encrypted one (still modified with the user's umask)
>> would be more appropriate. So in my opinion this does not warrant
>> a CVE but improvement in the upstream gnupg code would be
>> appreciated I think.
>
> Any security weakness can qualify for the E in CVE. Really the
> point
No, security vulnerabilities qualify, security hardening does not
necessarily qualify.
In this case GnuPG respects umask. We can't assign a CVE for every
single program that has potentially sensitive output and fails to
ensure that the output is mode 0600 or whatever (what about extended
access controls?). Some programs choose to enforce permissions within
themselves (e.g. OpenSSH and key based authentication), but generally
speaking makeing sure a program with potentially sensitive output is
safe is the job of the system configuration, and you have several options:
1) a safe default umask
2) using safe directory permissions, for example in RHEL /home/$USER
is not accessible by group or other
Again, it is nice if the program does this, but if the program does
not it's not generally considered a security vulnerability (of course
exceptions exist, for example servers that log username/password to a
world readable log file for example). But this is not one of those
exceptions.
> of CVE is increasing awareness. So whether any issue is a very
> minor E is really immaterial, but lets give it a number so those
> who actually care can become aware and take action.
>
> Best wishes, Mike
>
- --
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.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQXK9qAAoJEBYNRVNeJnmT9QMP/1yNU5yQoq/7rAZmDW9Q8HUh
FjU4XTXHXt7V1lNajstrr979oSJffD7d4A4S8kkjrgsOz8ZJ5QASnomk6Wa66Wtj
nVTtHnjDmtiNsc4rVGDm8fnD69tHayUVWaPtTavtCmqSG2WdPaU2+ilS1mtNmzFB
NtB/qvV/J5yFkicWz5NDrckblt8tkhTFPwdGXBu1jmuZvfN0puXpxdX7C3oX76x+
ZDSgzk8eYyLPNOUxEnyR3OixtNoHPH1jwu6VjH/rZfQU/ulSwWcgl+yCGJ7+Xf8t
sDmyy6O2SltYWLBuMVFUvV64EeleZsPYr4XtJhok4AUKr1VxLUiYMQ7zCDlWJVBv
YjQaaqNvDizBX+EOzy3KcpkHLpeYy22o94ByiUimeeNBv/QEWEO4blYXI2VYbhDe
/7jNqxBPGbsrrFDm34w8UtbY/NN3lZvR7sW02XCCGaQHyEY+to3y9t4noR/kw2kk
0NTQ4N6dLgS8ueXB41/Q9oXoWH9XDSWmuDUWcgXy7waQMWN9Qi7NlRLZTP7R9HxW
Y45tJU0fJywTw1TV5ypJtALU0xHbW+aX1byzf5U7fAO65w0QqUx2/1o/Lpse2Es4
Gpndh5YzgqSky9ZJ4baBhKeyHlaNtBMt2KY5pWyyWGqK74UWUJLtOPYYsBracZQV
+bn0dXBl7WvUIvDBP+dp
=f2Xw
-----END PGP SIGNATURE-----
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.
