[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130904215001.GQ32641@redhat.com>
Date: Wed, 4 Sep 2013 15:50:01 -0600
From: Vincent Danen <vdanen@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: unauthorized host/service views
displayed in servicegroup view
* [2013-09-04 11:25:21 -0400] Daniel Kahn Gillmor wrote:
>[dropping cc's, just leaving oss-security]
>
>On 09/03/2013 07:02 PM, Vincent Danen wrote:
>
>> I mean, if someone wants to shoot themselves in the foot and document it
>> as a feature, who are we to say otherwise? We may not agree with it,
>> but it's a documented feature (deliberately changed), so we can't just
>> very well call it a security flaw because we don't like the new
>> behaviour.
>
>I'm curious about this. If, say, a modern TLS library some day decides
>to get around to implementing (old, deprecated, known-insecure,
>previously-unimplemented) SSLv2, and announces it as a feature, and
>enables it by default, is the consensus of this group that we would not
>treat it as worthy of a CVE, despite being a clear security weakening?
>
>At what point does the security community override the upstream
>decisions and declare the packages vulnerable?
That's a good question. For your example, I'd say that's a bad thing...
we all know SSLv2 is insecure and we would consider the developer to be
a little "special" in the head, I think. =)
This is a bit different though. The users are authenticated -- it's not
unauthenticated exposure. How granular the access controls _within_
that application are largely depend on the developer. It might be
different if they decided to chuck the whole authentication basis and
decided that information in Nagios should be public. But, even then,
that is a definite design decision -- is it still a security flaw?
Arguably, Google searches often reveal sensitive information -- does
that mean Google searches require a CVE? Or is that up to the end user
to decide "this has too much risk" or "I disagree with the design
decision here and will suit something better to my use-case"?
So while I think you have a valid question, I think the first question
is what constitutes a security flaw -- once that is defined, then I
think what upstream does is irrelevant. If it's a flaw, it's a flaw.
And obviously upstream's point of view is sometime questionable -- it's
like the Linux kernel folks deciding there are no security bugs, only
_bugs_ (with no distinction). That never went over very well. =)
--
Vincent Danen / Red Hat Security Response Team
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.
