[Pkg-nagios-devel] Bug#849417: Bug#849417: nagios-nrpe-server: segfault during SSL negotiation with older NRPE 2.15 plugin

[Sebastiaan Couwenberg]

On 12/28/2016 07:07 PM, Adam Di Carlo wrote:
> Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:
> 
>> As documented in /usr/share/doc/nagios-nrpe-server/NEWS.Debian.gz which
>> is shown to you on upgrade when you have apt-listchanges installed:
> [...]
>>   Beware that the new NRPE daemon only works with old check_nrpe
>>   plugins when SSL support is disabled on both sides, likewise the
>>   new check_nrpe plugin only works with the old NRPE daemon when SSL
>>   support is disabled.
> 
> Oh!  I totally didn't see that.  Ok.  So what I'm trying to do will
> never work and I need to disable SSL for all NRPE servers as well as on
> my (Jessie) nagios server.

You only need to disable SSL for NRPE >= 3.0. The SSL support for NRPE
2.x still works.

For example, on my jessie server I changed the check_nrpe commands to
match the configuration in NRPE 3.x (see attached check_nrpe.cfg) by
modifying /etc/nagios-plugins/config/check_nrpe.cfg.

In the service configuration I changed all check_nrpe_1arg commands to
check_nrpe_ssl, and for the hosts running testing/unstable I changed it
to check_nrpe. Once the jessie systems get upgraded to stretch their
service configuration will be changed to use check_nrpe instead of
check_nrpe_ssl too.

>>   To use SSL between the NRPE client and server, configuring Stunnel
>>   is recommended.
> 
> I suppose that disabling SSL, so long as I also disable the NRPE
> argument processing on the older NRPEs which allow it, won't create too
> many security issues on an internal network.  The most an attacker could
> do, assuming they could spoof my the one allowed IP that commands can
> come from, is run the checks configured on the NRPE server.  So, there
> is a denial-of-service risk here but not much more than that....

The SSL support in NRPE 2.x never got you much security on your internal
network (it did not verify the hostname for example), it mostly
obfuscated tcpdumps. Disabling the NRPE arguments brings you much more
security that the (broken) SSL support in NRPE 2.x.

> Pardon me for failing to RTM here.
> 
>> Due to the signal handler in NRPE you won't easily get a backtrace since
>> SIGSEGV is caught too and NRPE just continues instead of terminating. If
>> you can get a backtrace (with debug symbols installed) that would be
>> helpful.
> 
> Ok, I'll give it a whack.  Lets leave the bug in "moreinfo" until I get
> that.  I do believe I need to rebuild the package with '-g' to get
> symbols out, which I've done.  Off to work for now but I'll give this
> another attempt, should have result by no later than end of day tomorrow.

The debug symbols are already available, no need to a rebuild. Just
install the nagios-nrpe-server-dbgsym package. You may need to configure
the sources for that first, e.g. for unstable:

# Debug packages
deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main
contrib non-free

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
-------------- next part --------------
# this command runs a program $ARG1$ with no arguments and disables SSL support
define command {
	command_name	check_nrpe
	command_line	/usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -n
}

# this command runs a program $ARG1$ with no arguments and enables SSL support
define command {
	command_name	check_nrpe_ssl
	command_line	/usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}