Security issue

[Andreas Ericsson]

Ton Voon wrote:
> On 27 Oct 2008, at 08:51, Andreas Ericsson wrote:
> 
>> The rest of the nagios-devel mailing list, you may want to mark this
>> thread as important, although an announce will be sent once the issues
>> Tim discovered have been fixed.
> 
> I notice that there have been patches applied to Nagios for this  
> issue, but it is not clear what the security issue is.
> 
> Can you explain what the issue is, what the exposure is, and what the  
> fix does?
> 

There were actually two different vulnerabilities. One resulted in cmd.cgi
potentially accepting commands from low-privileged users that those users
should not have been able to submit. This issue has been fixed completely.
Those interested in the details can find them either in the Nagios CVS
repository, or in my git clone of the same at git://git.op5.org/nagios.git

The other is the CSRF attack described in more detail below.

Nagios CGI's are vulnerable to a Cross Site Request Forgery attack (csrf).
A CSRF attack requires a couple of things for it to work, and it relies
on the webs abilities (or rather, the browser's abilities) of posting
form-data to a site which is other than that of the site presenting the
form.

Here's how it works:
Unsuspecting Nagios Admin (UNA from now on) logs on to the Nagios server
and checks the status of his/her network. Since everything's ok, UNA
decides to leisurely browse evilsite.com, controlled by Dr Evil.

On evilsite.com, there's a page containing a bog-standard web form, but
with some hidden variables and an 'action' tag that points to UNA's
cmd.cgi on UNA's Nagios server. When UNA submits the form, Dr Evil has
all of a sudden sent data of his/her choice to the responding page
on UNA's site. It's important to note that UNA's browser is being used,
as it leads to a couple of interesting things:
* UNA sees the output from cmd.cgi. It's never sent to evilsite.com,
  which can only guess if the attack was successful or not.
* Firewalls can not be used to defend against this, as UNA requires
  access to the Nagios server in order to work.
* Cookies can't be used either, as they are helpfully sent to the
  Nagios server whenever the browser loads a page from it.

Why is this bad, then? Well, it's not so evil in itself, and the most
horrible thing that it should have lead to was Dr Evil being able to
enable / disable notifications or stuff like that, but in Nagios 3
we gained the ability to change checkcommand arguments and suchlike,
which, combined with the csrf above, ultimately led to Dr Evil being
able to run any command of his/her (who says girl's can't be evil?)
choice on UNA's preacious Nagios server as the Nagios user.


So what's the remedy?
Well, a proper remedy is to implement in-form session tokens, which
makes sure that the form submitted by the user came from the site we
would like it to have come from (namely our humble selves). I'm
working on that right now, and hope to have it done by this afternoon.
It's been loads of fun implementing that in super-paranoid C, by the
way. :-)

In the mean-time, we've blocked use of the CHANGE_ commands from the
CGI's, and also made sure that multiple commands can't be submitted
as one (fe by using comments with newlines). This interim remedy
brings the worst-case scenario down from remote command execution to
a more prank-like level (acknowledging problems, adding or deleting
comments, etc, etc).


A couple of things to note:
* Information disclosure is not possible. No remote user can see
  anything from your authentication-protected Nagios servers.
* Invalid commands read from the FIFO are always dropped flat by
  Nagios.
* Since commands must be valid, it's not very easy to submit a
  command that has all the information required. Social engineering
  is required.
* You *will* notice if this happens to you, since you all of a
  sudden will end up with cmd.cgi (not in a frame either) saying
  "Command submitted successfully" or some such.


Hope that clears things up a bit.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/