Tim Starling of the Wikimedia foundation reported a cross-site request forgery vulnerability affecting cmd.cgi, affecting Nagios versions up to and including 3.0.5.

A cross-site request forgery means that one site includes a <form> tag with an "action" value pointing to a different site. The idea is to utilize a user's already valid session with a site requiring authentication to submit forms to that site that the user didn't intend to submit.

For Nagios, the scenario looks like this:
1. Random Nagios Admin (RNA) logs in to nagios, supplying valid credentials.
2. RNA goes to evilsite.com, where some lurid java-script checks his browsers history and notices that RNA has a Nagios installation by looking at the previously browsed pages.
3. evilsite.com creates a form which, using hidden variables, submits a command to the Nagios site where RNA is an admin.
4. Since RNA is authenticated with valid credentials, the command is accepted and Nagios loads it as if RNA had submitted it himself (which, for all that cmd.cgi on the nagios server knows, he/she has).

With Nagios 2, the worst that could happen is that evilsite.com disables monitoring of the network, or submits any of the other commands that Nagios accepts (invalid commands are simply discarded by the Nagios core).

The remedy to this is a patch that I wrote, which I hope will go into Nagios 3.0.6, to be released Any Day Now(tm).

The fix I wrote works like this:
1. When RNA wants to submit a command, he/she is sent to the command submission page (the one with the 'commit' button).
2. The command submission page generates a random token that gets included as a hidden variable in the form. The session data (apart from the random numbers) is also written to disk.
3. When the 'commit' button is pressed, the session token is looked up and cmd.cgi makes sure the session is valid (ie, belongs to the right user and is less than 15 minutes ols). If there is no valid session token, command submission fails and the user is told so.

What really kills the ability for off-site forms to circumvent this is the fact that the session token gets written to disk. Even if someone manages to guess the pseudo-random SHA1 session token (which is 2^160 to 1 against) they still can't make that session valid by writing it to the nagios-server's disk.

The CSRF issue is still in Nagios 3.0.5, but can no longer trigger execution of arbitrary programs by the Nagios process due to the changes made to prevent malicious exploitation of CVE-2008-5027. Its impact is thereby reduced to disabling monitoring of the network and similar actions that can validly be requested from the Nagios process through the GUI. Bad enough, but no longer a vulnerability that allows a remote attacker to run arbitrary programs on the one server in your network that can bypass every firewall one way or another.

I'm withholding the CVE details until Steven has had time to update the information with that contained in the above paragraph. In case I forget to update this blog-post, the CVE candidate id is CVE-2008-5028.

A fixed version of Nagios is available at http://www.op5.org/src/nagios-3.0.5p1.tar.gz. This fixed version is the base of op5 Monitor 4.0.1 which no longer suffers from the vulnerability discussed here.