Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 21 Sep 2012 12:18:18 -0600
From: Kurt Seifried <>
CC: Michael Gilbert <>
Subject: Re: Re: CVE request(?): gpg: improper file permssions
 set when en/de-crypting files

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]
>>> 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

> 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

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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.