Bug 978531 - (CVE-2013-2214) CVE-2013-2214 nagios: unauthorized hosts and services displayed in servicegroup view
CVE-2013-2214 nagios: unauthorized hosts and services displayed in servicegro...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20130506,repor...
: Security
Depends On: 978535 978536 978738 979075
Blocks: 978545
  Show dependency treegraph
 
Reported: 2013-06-26 14:21 EDT by Vincent Danen
Modified: 2016-04-26 10:48 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-02 13:40:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2013-06-26 14:21:01 EDT
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.  Discussion on this problem is available [1], as well as the original bug report [2].

[1] http://www.mail-archive.com/nagios-users@lists.sourceforge.net/msg39749.html
[2] http://tracker.nagios.org/view.php?id=456
Comment 1 Vincent Danen 2013-06-26 14:24:45 EDT
Created nagios tracking bugs for this issue:

Affects: epel-6 [bug 978535]
Affects: fedora-all [bug 978536]
Comment 2 Vincent Danen 2013-06-26 14:31:21 EDT
A patch is attached to the upstream report that is reported to work.
Comment 3 Kurt Seifried 2013-06-26 15:44:08 EDT
Added CVE as per http://openwall.com/lists/oss-security/2013/06/26/9
Comment 5 Lon Hohberger 2013-07-05 15:11:10 EDT
The description of the exploit seems a bit thin on information, or perhaps our existing release is unaffected.

I created 2 service monitoring scripts for watching mysqld and httpd.  I assigned each to a service, and each of these services to a single service group.

I created 5 users using 'htpasswd', and assigned them to 5 contacts.  I then created two contact groups and assigned the users as follows:

  test0 - [no groups]
  test1 - web
  test2 - web
  test3 - db
  test4 - db and web

I assigned each contact group to a service.

*WITHOUT* the proposed fix:

  test0 could see nothing at all about any service group
  test1 and test2 could only see the 'web' service group
  test3 could only see the 'db' service group
  test4 could see both service groups.

I repeated this test using 'contacts' for each service group instead of 'contact_group'.  The effect was the same whether using 'contacts' or 'contact_group' in the service group definition; none of the links reported showed the 'db' service group to those outside the group.

After applying the (reversed) patch, I added 'test1' to the 'authorized_for_all_hosts'.  When logged in as 'test1', everything worked as expected; I could still monitor the 'web' service group but not the 'db' service group.

If I logged out and logged in as 'test2', however, without the 'authorized_for_all_hosts' set for that account, I was unable to see the hosts for the 'web' service at the following links:

  http://localhost/nagios/cgi-bin//status.cgi?servicegroup=all&style=overview
  http://localhost/nagios/cgi-bin//status.cgi?servicegroup=all&style=summary
  http://localhost/nagios/cgi-bin//status.cgi?servicegroup=all&style=grid

Unfortunately, I *WAS* still able to see hosts here:

  http://localhost/nagios/cgi-bin//status.cgi?servicegroup=all&style=detail

I think the problem needs a much clearer reproducer; as I believe the behavior is consistent with what Andreas said here:

  http://www.mail-archive.com/nagios-users@lists.sourceforge.net/msg39783.html

If, however, the intent was to require authorize_for_all_hosts in order to have a host visible to a user, then I believe the patch is incomplete.
Comment 6 Lon Hohberger 2013-07-05 15:26:35 EDT
The behavior was the same with 3.4.1 and 3.4.4.
Comment 7 Lon Hohberger 2013-07-05 15:45:30 EDT
(In reply to Lon Hohberger from comment #5)

> After applying the (reversed) patch, I added 'test1' to the
> 'authorized_for_all_hosts'.  When logged in as 'test1', everything worked as
> expected; I could still monitor the 'web' service group but not the 'db'
> service group.

My notes were bad here: if I logged in as 'test1', I could see both service groups if test1 was authorized for all hosts.  That is, pre- and post-patch were consistent.

Logging in as test0 let me see nothing.

Logging in as test2 let me see the 'status summary' for the web service, but said there were no matching hosts.  If I clicked this link, it would then show me localhost (but clicking on the 'localhost' link did nothing):

  http://localhost/nagios/cgi-bin//status.cgi?servicegroup=all&style=detail

Logging in as test3 let me see the 'status summary' for the db service, but said there were no matching hosts.  Going to the above link showed me localhost.

Logging in as test4 let me see the 'status summary' for the db and web services, but said there were no matching hosts for both.  Going to the above link showed me localhost.
Comment 8 Lon Hohberger 2013-07-05 15:55:04 EDT
It seems that when authorized for a service group, the ability to see both all services in the group is expected behavior.  Similarly, when assigned as a contact role for a service, all hosts running that service are visible to the user.
Comment 10 Lon Hohberger 2013-07-10 13:52:22 EDT
Ok, I discussed this some more with the original reporter here:

http://tracker.nagios.org/view.php?id=456

The heart of the matter is that if a user has permissions to view/manage a service, that user can see *all hosts and services in the group that service is in*.

I attached a configuration file to the upstream ticket showing the problem.  I think the fix goes a bit too far; I believe it unintentionally changes the behavior of the summary screens for service groups in most cases.

I'm following up with the original reporter.
Comment 11 Lon Hohberger 2013-07-11 12:04:46 EDT
I reproduced the purported problem and noted a reproducer configuration in the above link.

Reading the code in cgi/cgiauth.c, it appears that being a contact for one service *intentionally* gives you access to view other services (and associated hosts) in the group since 3.3.2 (this is from the 3.4.4 code base):

/* check if user is authorized to view information about all services in a particular servicegroup */
int is_authorized_for_servicegroup(servicegroup *sg, authdata *authinfo) {
        servicesmember *temp_servicesmember;
        service *temp_service;

        if(sg == NULL)
                return FALSE;

        /* see if user is authorized for all services in the servicegroup */
        /*
        for(temp_servicesmember = sg->members; temp_servicesmember != NULL; temp_servicesmember = temp_servicesmember->next) {
                temp_service = find_service(temp_servicesmember->host_name, temp_servicesmember->service_description);
                if(is_authorized_for_service(temp_service, authinfo) == FALSE)
                        return FALSE;
                }
        */
        /* Reverted for 3.3.2 - must only be a member of one hostgroup */
        for(temp_servicesmember = sg->members; temp_servicesmember != NULL; temp_servicesmember = temp_servicesmember->next) {
                temp_service = find_service(temp_servicesmember->host_name, temp_servicesmember->service_description);
                if(is_authorized_for_service(temp_service, authinfo) == TRUE)
                        return TRUE;
                }

        /*return TRUE*/;
        return FALSE;
        }

(Note the fabulous typo in the comment due to a cut/paste) The same is true for hostgroups as well: if you're a contact for one host, you can see other hosts in the same group. The code *and* comments appear to indicate that a user set as a contact to one service in a group should be able to see all of the services in that group when using service group displays (and, when you can see a service, you can see the hosts too).

It appears that this is done because servicegroup and hostgroup object definitions do not have a way to specify contacts/contact_groups like most other objects.

I think this is a misunderstanding and that this is working as designed, but I did ask one of the maintainers for clarification.

There changes we could make to make the ACL mode a bit tighter without breaking behavior on existing installations; I have no problem exploring these, but since the current behavior appears to be by-design, I am not convinced this is a security problem.
Comment 12 Lon Hohberger 2013-07-15 15:45:27 EDT
Also in the changelog:

http://www.nagios.org/projects/nagioscore/history/core-3x

... is:

* 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)
Comment 13 Vincent Danen 2013-07-18 17:47:50 EDT
Lon, thanks for taking all that time to dig into this.  It does seem that this is by design after all, so perhaps this CVE should be rejected.  I will leave that to upstream to dispute (if it's intentional, it's not a security flaw).  This was introduced in 3.4.0.

If you agree with this, you can let upstream know that they can dispute this CVE, and we'll add a statement here indicating that we don't consider this a flaw, and close the bug.
Comment 14 Keiran Smith 2013-07-19 09:52:57 EDT
*** Bug 978536 has been marked as a duplicate of this bug. ***
Comment 15 Keiran Smith 2013-07-19 09:54:51 EDT
*** Bug 978535 has been marked as a duplicate of this bug. ***
Comment 16 Vincent Danen 2013-07-24 13:44:03 EDT
Keiran, you can't duplicate tracking bugs against this bug.  This bug is for the flaw itself, those other bugs are to track the status of the fix in various products.  Please don't do that.
Comment 17 Vincent Danen 2013-08-02 13:40:39 EDT
Noted that this issue should be rejected and this is by design:

http://www.openwall.com/lists/oss-security/2013/08/02/3

I'm going to close this as NOTABUG since it is clearly upstream's intent to do this.
Comment 18 Vincent Danen 2013-08-02 13:42:51 EDT
Statement:

This is not a flaw; Nagios upstream implemented this as a feature, as documented in their changelog.

Note You need to log in before you can comment on or make changes to this bug.