Subject: Re: Security issue
Newsgroups: gmane.network.nagios.devel
Date: 2008-11-06 11:45:44 GMT (34 weeks, 3 days, 5 hours and 29 minutes ago)
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=/