Created nagios tracking bugs for this issue:

Affects: epel-6 [bug 978535]
Affects: fedora-all [bug 978536]

A patch is attached to the upstream report that is reported to work.

Added CVE as per http://openwall.com/lists/oss-security/2013/06/26/9

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.

The behavior was the same with 3.4.1 and 3.4.4.

(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.

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.

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.

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.

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)

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.

*** Bug 978536 has been marked as a duplicate of this bug. ***

*** Bug 978535 has been marked as a duplicate of this bug. ***

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.

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.

Statement:

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