Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1348223820.22489.36.camel@vespa.frost.loc>
Date: Fri, 21 Sep 2012 12:37:00 +0200
From: Tomas Mraz <tmraz@...hat.com>
To: Matthias Weckbecker <mweckbecker@...e.de>
Cc: oss-security@...ts.openwall.com, vcizek@...e.de
Subject: Re: CVE request(?): gpg: improper file permssions set when
 en/de-crypting files

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.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

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.