[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANTw=MOVE0H=jqGX28Vb+DKKFC4cqxf7juoSPagc0c+TRuu3qA@mail.gmail.com>
Date: Fri, 21 Sep 2012 11:31:47 -0400
From: Michael Gilbert <mgilbert@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE request(?): gpg: improper file permssions
set when en/de-crypting files
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
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
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.
