[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51FDA2EC.7040407@freesources.org>
Date: Sun, 04 Aug 2013 02:40:12 +0200
From: Jonas Meurer <jonas@...esources.org>
To: Vincent Danen <vdanen@...hat.com>
CC: oss-security@...ts.openwall.com, kseifried@...hat.com,
contribute@...ios.org
Subject: Re: CVE request: unauthorized host/service views displayed
in servicegroup view
Hello,
sorry, I'm on holidays and cannot work on this issue for the next two
weeks. But I think that there is a missunderstanding. See my short
comment below.
Am 02.08.2013 19:27, schrieb Vincent Danen:
> * [2013-07-10 17:17:08 +0200] Jonas Meurer wrote:
>
>> Hello,
>>
>> Am 2013-07-08 20:16, schrieb Kurt Seifried:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 06/26/2013 01:42 PM, Kurt Seifried wrote:
>>>> On 06/26/2013 12:36 PM, Vincent Danen wrote:
>>>>> I don't believe a CVE has been assigned to this issue yet.
>>>>
>>>>> It was reported that Nagios 3.4.4 at least, and possibly earlier
>>>>> versions, would allow users with access to Nagios to obtain
>>>>> full access to the servicegroup overview, even if they are not
>>>>> authorized to view all of the systems (not configured for this
>>>>> ability in the authorized_for_* configuration option). This
>>>>> includes the servicegroup overview, summary, and grid.
>>>>
>>>>> Provided the user has access to view some services, they will be
>>>>> able to see all services (including those they should not see).
>>>>> Note that the user in question must have access to some services
>>>>> and must have access to Nagios to begin with.
>>>>
>>>>> This has not yet been corrected upstream.
>>>>
>>>>> References:
>>>>
>>>>> http://www.mail-archive.com/nagios-users@lists.sourceforge.net/msg39749.html
>>>>>
>>>>
>>>>> http://tracker.nagios.org/view.php?id=456
>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714171
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=978531
>>>>
>>>>
>>>>> Thanks.
>>>>
>>>> Please use CVE-2013-2214 for this issue.
>>>
>>> It appears there are may be some problems with this issue, potentially
>>> this may have been a bad configuration and not a source code based
>>> problem, however we haven't been able to confirm it yet. I've also not
>>> been able to contact upstream about this easily (no security@ address,
>>> if anyone know whom to forward this to, please let me know, thanks.
>>
>> I'm wondering why you fail to reproduce this issue. I posted some
>> details regarding my setup at the Nagios Tracker:
>> http://tracker.nagios.org/view.php?id=456
>>
>> Unfortunately Nagios upstream sometimes rather unresponsive. At least
>> that's what I observed.
>>
>> Please let me know if you need any further details regarding the bug
>> or advice on how to reproduce it.
>
> To close the loop on this, the CVE should probably be rejected.
> According to upstream, this is done by design. One of our users noted
> it in our bugzilla:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=978531#c11
>
> He has a thorough explanation, but the bottom line is this seems to be
> by design, as noted in the changelog:
>
> http://www.nagios.org/projects/nagioscore/history/core-3x
>
> * Users can now see hostgroups and servicegroups that contain at least
> one host or service they are authorized for, instead of having to be
> authorized for them all (Ethan Galstad)
As I understand this changelog entry, it means the following:
Hostgroups and servicegroups are listed with all the _authorized_
members if the user is authorized to see at least one member.
To me it doesn't mean the following (which was the case without my patch):
Servicegroups are listed with all members (regardless wether authorized
or unauthorized) if the user is authorized to see at least one member.
Another argument for my point of view is that the nagios maintainers
(silently) accepted my patch (at least if I remember correctly, it has
been incorporated into the upstream development repository).
Unfortunately there's still not one single statement from upstream about
the issue, that I'm aware of.
> I suspect this CVE should be rejected as this is done by design.
Like explained above, I disagree with this suggestion :)
Kind regards,
jonas
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.
