"corrupted size" when checking NSClient++ NRPE server on i386 architecture

sebastic commented 6 years ago

As reported by Samuel Bizien Filippi in Debian Bug #895813:

When using:

check_nrpe (v3.0.1 from stretch as well as v3.2.1 from stetch-backports) on i386 architecture

NSClient++ on server side (NSClient++ v0.5.2.39 on Windows x86_64)

TLS encryption for the communication

e.g. running the command line :
/usr/lib/nagios/plugins/check_nrpe -H checked-windows.local -c check_cpu -A ca.crt -K client-checker.key -C client-checker.crt -S TLSv1.2
The check_nrpe fails with the message :
*** Error in `/usr/lib/nagios/plugins/check_nrpe': corrupted size vs. prev_size: 0x004320b8 ***
(and a backtrace, and not the output expected)

Note that the same program works with :

check_nrpe running on x86_64 architecture

OR disabling TLS encryption

OR using nagios-nrpe-server on the server side

When setting the environment variable MALLOCCHECK=2, it displays the expected output (at least from the package rebuilt with debug symbols), but then aborts with return code 134.

I attach with the bug reports the backtrace from gdb and packet captures as follows :
$ /usr/lib/nagios/plugins/check_nrpe -H checked-debian.aptm.local -n -c check_load
OK - load average: 0.08, 0.19, 0.25|load1=0.080;15.000;30.000;0; load5=0.190;10.000;25.000;0; load15=0.250;5.000;20.000;0;
-> nrpe_nagios.pcap
$ /usr/lib/nagios/plugins/check_nrpe -H checked-windows.aptm.local -c check_cpu
OK: CPU load is ok.|'total 5m'=0%;80;90 'total 1m'=0%;80;90 'total 5s'=0%;80;90
-> nrpe_nsclient.pcap
$ /usr/lib/nagios/plugins/check_nrpe -H checked-debian.aptm.local -c check_load -A ca.crt -K client-checker.key -C client-checker.crt -S TLSv1.2
OK - load average: 0.17, 0.15, 0.14|load1=0.170;15.000;30.000;0; load5=0.150;10.000;25.000;0; load15=0.140;5.000;20.000;0; 
-> nrpe_nagios_tls.pcap
$ /usr/lib/nagios/plugins/check_nrpe -H checked-windows.local -c check_cpu -A ca.crt -K client-checker.key -C client-checker.crt -S TLSv1.2
*** Error in `/usr/lib/nagios/plugins/check_nrpe': corrupted size vs. prev_size: 0x022530b8 ***
[...]
-> nrpe_nsclient_tls.pcap

Also note that when building the package from the sources with fakeroot apt-get -b source -t stretch-backports nagios-nrpe-plugin, the compiler warns about incompatible types:
./check_nrpe.c:1352:79: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
      printf("CHECK_NRPE: Receive header underflow - only %d bytes received (%ld expected).\n", rc, sizeof(bytes_to_recv));
... but applying the patch to correct that little problem (attached) does not resolve the problem exhibited here.

Attached :
-  : different test cases, showing which one fails
- dbg.log containing the traces from gdb (without and with MALLOC_CHECK_=2)
- *.pcap : network traces of communication (the failing case is nrpe_nsclient_tls.pcap)
- ca.crt/client_checke{r,d}.{key,crt} : PKI used for the tests, if you want to reproduce.
- check_nrpe-printf.patch : correct the printf statements in check_nrpe.c (may be useful, but does not solve this problem).

Attachments:

hedenface commented 6 years ago

Thank you. There seems to be quite a bit of compatibility issues since the 3.2.0 release. This looks like the detailed output may offer some insight.

I'm spending a lot of time trying to get the Core 4.4.0 release out - but I will visit this as time permits. I'll at least push the printf() patch as soon as possible - who gets the credit for this? Samuel Bizien Filippi?

sebastic commented 6 years ago

I'll at least push the printf() patch as soon as possible - who gets the credit for this? Samuel Bizien Filippi?

Yes, all attachments were submitted to the Debian bugreport by him.

ArneKu commented 5 years ago

Hello, I'm experiencing the same problems. Do you have a workaround, yet? Greetings Arne

Fantu commented 3 years ago

is there any news on this please?

NagiosEnterprises / nrpe

"corrupted size" when checking NSClient++ NRPE server on i386 architecture #180