[op5-users] security update for monitor later today

Johannes Dagemark jd at op5.com
Thu Nov 6 16:16:53 CET 2008


Hello again

Sometimes things don't work as planned. A couple of more bugs, related 
to the security fix announced earlier, popped up during the day. We have 
decided to push the release until tomorrow.

Until then for those of you that does not read the nagios-users list, 
here is a description on the bug(s) that Andreas posted to the list.

------------------------------------------------------------

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.


------------------------------------------------------------


Best regards

-- 
Johannes Dagemark
VP Engineering
________________________________________

op5 AB
Första Långgatan 19
SE-413 27 Gothenburg
cell: +46 733-70 90 24
fax:  +46 31-774 04 32
Email: jd at op5.com
http://www.op5.com/


Johannes Dagemark wrote:
> Hey all
>
> Recently a security issue with Nagios was discovered. Andreas has been 
> working together with a couple of other persons in the Nagios 
> community to fix this and we will release an updated version of op5 
> Monitor later today.
>
> ------------snip from the nagios-devel mailing list-------------------
>
> it was a possible Cross Site Request Forgery Attack against the cmd.cgi
> which allows an authorized attacker to inject external commands to
> nagios. In worst case the attacker might execute any shell code.
>
> I don't want go deeper into this on public readable ressources. I've
> tested the possible attack and it was evil enough for me to update as
> soon as possible.
> ------------snip from the nagios-devel mailing list-------------------
>
>
> More info will be posted later today. It is highly recommended to update
>
> Best regards
>


More information about the op5-users mailing list