V3 Packets are not handled properly

[ziccardi]

Using the master branch, running the following command:

./check_nrpe -3 -n -H 127.0.0.1 -p 5666

Results in:

CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).
NRPE v4.0.2

In the end the results is returned (NRPE v4.0.2) because check_nrpe falls back to V2 Packets.

How to replicate

1. clone this repo
2. ./configure --disable-ssl
3. make all
4. create an NRPE.cfg file with the following content:

   log_file=/tmp/nrpe.log
   debug=0
   pid_file=/tmp/nrpe.pid
   server_port=5666
   nrpe_user=nagios
   nrpe_group=nagios
   allowed_hosts=127.0.0.1,::1
   dont_blame_nrpe=0
   allow_bash_command_substitution=0
   command_timeout=60
   connection_timeout=300
   disable_syslog=0

5. ./src/nrpe -c nrpe.cfg -n -f
6. ./src/check_nrpe -3 -n -H 127.0.0.1 -p 5666

As an added info, it works correctly with packet version 2 (with the -2 flag instead of the -3 one)

[sawolf]

If I'm reading correctly, this is expected behavior. The purpose of check_nrpe -3 is to keep a system "working" in the event that you cannot (or are unwilling to) deploy the NRPE v4 daemon to an already-monitored host. The NRPE v4 daemon should never process v3 requests.

[ziccardi]

@sawolf I didn't look too much through the NRPE code, but according to

• https://github.com/NagiosEnterprises/nrpe/blob/master/src/nrpe.c#L1916 and
• https://github.com/NagiosEnterprises/nrpe/blob/master/include/common.h.in#L80

I would say that the only unsupported version should be version 1

[sawolf]

Okay, based on how the code is structured, I can see why you'd say that.

However, if you look through the issues that led up to the 4.0.0 release, there were several security issues which motivated the new version. In particular, there are ways to crash the NRPE v3 daemon by sending a command from an arbitrary host, and we know there are issues with packet length calculation, which can lead to buffer overflow attacks (though the reporter didn't find any themselves). Version 4 was released to eliminate those issues, and the way we eliminated them made it incompatible with version 3 packets.

As for why the code is structured that way, there's a lot of repeated code in the repository. Since new development is happening on a different agent, I mostly made the same few changes everywhere instead of refactoring the code.

[ziccardi]

@sawolf Got it! Then, since NRPE is able to know the version of the packet it receives, I believe the error message should be different (something like 'Unsupported protocol version: 3'). Thank you!

[rpv-tomsk]

The NRPE v4 daemon should never process v3 requests.

Why it still able to process v2 packets then? Breaking support for v3 packets in 4.x agent does not solve problems with "vulnerable" 3.x agents.

As the packet parser code is the same for v3 and v4 with only one exception is "3 bytes padding", I think, there is one of:

• New 4.1 version of agent is not "vulnerable" and able to handle both v3 and v4 packets
• New version still "vulnerable" for both v3 and v4.

I hope for first case.

Also, most of your changes, as seen in git diff nrpe-3.2.1 nrpe-4.1.0, shows you made much work for NRPE_PACKET_VERSION_3 support in new branch. And only small minor flaws breaks it.

Also, release notes confirms what v3 should be supported:

Note: This update includes security fixes which affect both the check_nrpe plugin and the NRPE daemon. The latest version of NRPE is still able to interoperate with previous versions, but for best results, both programs should be updated.

I will publish PR soon which fix this issue (support for v3 packets in 4.1.x agent) We use it while migration - we have old hosts with v3 agents and new with v4, and no configuration changes on Nagios side required while hosts are in upgrade. So, I think fix will be useful for other people too.