[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120524205730.GA4095@openwall.com>
Date: Fri, 25 May 2012 00:57:30 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE Request: powerdns does not clear supplementary groups
Kurt -
On Thu, May 24, 2012 at 02:33:06PM -0600, Kurt Seifried wrote:
> [...] when a program
> with much more limited operations doesn't drop privileges, unless it
> directly leads to some sort of exploit/elevated access/etc. than I'm
> inclined to say while it's not good, it's not a vulnerability per se.
It's a case of a security feature not working as intended. Previously,
CVEs were sometimes assigned and sometimes not in such cases, and I
failed to see a pattern in that. ;-) Consider e.g. CVE-2006-5794 ("it
is believed that this issue is only exploitable by leveraging
vulnerabilities in the unprivileged process, which are not known to
exist"). Are you maybe trying to draw the line between "security
feature" and "security hardening"? Even if so, I fail to see how
OpenSSH's privsep is more of a "security feature", whereas another
daemon's dropping of root privs is "security hardening". These look
very similar to me in terms of what they're intended and expected to
achieve, so I think it's the same category, whatever we call it.
Now, I imagine there could be a subtle case if e.g. a downstream distro
or a fork of a project introduces privilege dropping, which is not in
the main code base, and there turns out to be a flaw in that, which
weakens the added security (but not to the point of being worse than the
original). It would feel a bit weird to say that the hardened revision
is vulnerable whereas the original is not, even though the original is
not any safer. In such cases, I guess whether this is CVE-worthy or not
will depend on whether the added hardening was advertised to and
expected by users/admins of the hardened revision or not. If it was an
undocumented extra, then it failing to improve things is probably not
what people would expect to be tracked as a security vulnerability.
However, if it was documented and expected to function, then it becomes
a vulnerability to track just like any other one of similar severity.
I hope this helps.
Alexander
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.
