[Pkg-nagios-devel] Bug#547092: Bug#547092: Bug#547092: nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems

Mon Feb 20 14:31:43 UTC 2012

On Mon, 2012-02-20 at 14:05 +0100, Michael Friedrich wrote:
> https://git.icinga.org/?p=icinga-nrpe.git;a=commit;h=025334c19f252f43c4ae8209ff1eec889908478b
> https://git.icinga.org/?p=icinga-nrpe.git;a=blobdiff;f=src/nrpe.c;h=1618be253465e3201ca0c988e176727f77abf8fa;hp=f5859b7a0c4c0aea7246a75fdf0d4c712106c68a;hb=025334c19f252f43c4ae8209ff1eec889908478b;hpb=b3eacf64ff33198c300f8ae72c77eedc91095093
Well but IMHO this rather solve the whole problem, just breaking with
the old code, which was useless anyway.

> > The other Nagios NRPEs (that could be used on remote host sides) which
> > still use the fake SSL?
> that code is not (yet) compatible. feel free to provide upstream patches 
> which solve that compatibility breakage problem.
I'm not sure whether there should be any desire to make anything
compatible to the old way.

I think that old design is inherently broken even if one would make the
DH params configurable (i.e. not hard coded into the code and thus
adaptable per sysadmin)... then it would have to be the same for one
icinga cluster, right?

Given that you have easily thousands of nodes,... if one of them is
compromised (or just users read the binary) they know the DH params and
could be even able to attack something.

So I guess the right way to do this is: one shared secret per nagios<->
remote host connection.

When using SSL, the certificate approach seems best to me. But I'm not
sure if this contradicts one of the main goals of NRPE (performance).

> the packaged version remains "rather useless" as the generated dh key 
> happens on configure. so installing the built binary package isn't that 
> security aware, though the source install does generate a new dh key 
> everytime you call configure. by that means, upstream probably does not 
> see the opportunity to include such patches/changes with high priority.
Well but in the real world, no one is going to compile them manually.
And still, you'd have one shared secret for the whole cluster.

> and with upstream, i do mean the official nagios nrpe project. the 
> icinga one is just an unofficial fork
What do you mean? That the Icignga NRPE is not officially distributed by
Icinga itself?

That would be bad of course :-(

> if you got any better (aka a valuable patch), provide those please 
> instead of just nagging the package maintainers for things people know 
> for at least 5 years already. do something about it.
Well it seems there are patches, which solves the issue already in a
secure way.

For the reasons I've pointed out above, I believe that the
one-set-of-DH-params per cluster is broken by design.
So while I guess that it should be fairly easy to make a patch that
simply can both (e.g. one --ssl-dh and one -ssl-certificates) option, I
don't see much reason of wasting effort into it.

> mentioned bug with nrpe and ssl is such a thing and can truly understand 
> that alex does not want to patch his packages when upstream source 
> compiled builds behave differently.
Well it really seems that at least the nagios upstream will never change
this..

> you should probably start a discussion on nagios-devel mailinglists, 
> where the developers of nrpe read and write. that discussion must be 
> moved upstream, and not into the package space imho.
Yeah you're right,... I've just commented here, as I thought it
shouldn't be much of an effort to just integrate the patch in Debians
nagios nrpe...

With respect to upstream, I personally will rather trying to contribute
to icinga (and their nrpe) if this is still necessary.
I mean as you pointed out there really is a reason why we have forks,
I'd be happy if the original nagios just dies and all folks move to the
community supported Icinga.

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5677 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20120220/a2ce31ce/attachment.bin>