Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Sep 2010 15:15:44 -0400 (EDT)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: Josh Bressers <bressers@...hat.com>
cc: oss-security@...ts.openwall.com
Subject: Re: Minor security flaw with pam_xauth


On Tue, 21 Sep 2010, Josh Bressers wrote:

>> The same commit also introduces previously-missing privilege switching
>> into pam_env and pam_mail.  Unfortunately, this pam_env and pam_mail fix
>> is incomplete: it only switches the fsuid (should also switch fsgid (or
>> egid) and groups), and it fails to check the return value from setfsuid()
>> (doing so would require duplicate calls to setfsuid(), like we do in
>> libtcb, or switching of euid instead - yet it is desirable).
>>
>
> This one is a bit on the tricky side. I'm going to call it "improper
> setfsuid use" so we can use just one CVE instead of two (as the flaws are
> related):
>
> Use CVE-2010-3430

Things get tricky once you get to such low levels of detail, and this is 
the area where there's a little bit of wiggle room.  At one level, you 
could call it "improper switching of privileges."  Or you could split at 
the level of the individual bugs.

One way that helps to clarify such things is: "if I fix X, will Y be 
rendered neutral?"  In this case, if you don't switch fsgid/egid and 
groups, you still have an unchecked return value that could cause problems 
if setfsuid() fails.  The converse also appears true - even if you check 
the result to setfsuid, you still run with the wrong group IDs.  (Note 
that this "independent bug fix" is actually the opposite of when you merge 
things of the same bug type, and this kind of approach will get more and 
more complicated as the more-obvious bugs get eliminated from the affected 
code).

In this case, I would argue for two CVEs.

- Steve

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ