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

Sat Mar 17 16:33:30 UTC 2012

Hey folks...

I found some time now to look into this issue again...

On Mon, 2012-02-20 at 13:58 +0100, Alexander Wirt wrote:
> SSL done right would mean that you couldn't talk with older nrpes anymore,
> yes.
...
> You would lose compatbility with other distributions.

Not necessarily... you could just switch over on both sides to the
"no-ssl" version.

For the plugin side this is easy and can be done on a per command basis,
right? So you could use no-ssl and the certficate-ssl as you like.

For the daemon side (i.e. other distros or old Debians) you could just
use start it with no-ssl.
Now you may argue that there may be several nagios/icinga servers that
use the same NRPE daemon,... and THEN one would get into troubles as
other nagioses/icingas would have to switch to no-ssl, too, which they
don't want (why??) perhaps. But even there's a easy solution, run two
nrpes on different ports.

On Mon, 2012-02-20 at 19:49 +0100, Michael Friedrich wrote:
> <dev hat on>
> the code was NOT useless. stop blaming the devs for that initial 
> implementation. do better than that - actually make it better.
> <dev hat off>
I just tried an compiled my own nrpe with different dh.h. From that one
I used the plugin with the daemon version from SUSE.
So that means plugin and daemon, each with a _DIFFERENT_ set of dh.h
parameters communicate.
And it worked just flawless, which is because anon DH is used, right?

I'm not really sure what you expect from
encryption/integrity/security/SSL but to my mind the above proves quite
clearly that the way NRPE uses SSL right now is absolutely useless,
unless you're looking for subtle ways to waste CPU power.

You must understand that the current way is not even like "one shared
secret"... it's just a unsecured (MiM-attackable) key agreement,... and
only afterwards data is encrypted.
Pointless.

> <users hat on>
> why do i have to upgrade my nsclient++ server which only supports the 
> old nrpe protocol? oh snap, nsclient++ dev refuses to implement
> the new nrpe protocol with ssl certs. fuck, i can't upgrade to the
> new version, 
> but i really really want to use e.g. ipv6 layer
> <users hat off>
That's a quite naive and stubborn way of thinking.
a) As above, users can simply deactivate ssl and everything keeps
working
b) This issue is a severe security problem. If the user want's security
(and I assume that, as he has enabled SSL) than he has probably an
interest to invest effort to get it really secure.

> same goes for any other addon / plugin making use of the
> nrpe protocol. 
> break the protocol, release a new version, depend on all other devs 
> wanting or willing to implement a new protocol version. hooray. got a 
> solution for that problem or never thought about that
> why compatibility 
> affects more than nrpe client and server communication?
In all doing respect,... I doubt you understand security... remember
when there was the SSL/TLS renegotiation flaw found in the protocol.
They had to change not only the implementations but even the protocol
itself to make it secure.
That's the way things are,... if you find out that security is not
guaranteed anymore you just have to break things if this is necessary.
Other ways you enter a funny but stupid path.

> > 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).
> is this just a wild guess, or on what tests are you building
> this thesis on?
That was just a wild guess, I mean whether SSL with certificates would
e.g. be slower than check_by_ssh

Originally I planned to make a patch that just merges both SSL ways,...
But my tests I mentioned above seem to imply that this anon-DH thingy is
not like a one-shared-secret (or I and/or Debian would have luckily
calculated the same DH params as suse did)...
Therefore it's really pointless and I won't do this... MiM attacks are
real and you cannot just tell your attackers "please don't do it"

Now be it as it be...
I guess we can discuss about this problem forever, but in the end it
comes down to the following:

- upstream (well at least the Nagios) seem to not understand/solve (or
has the time to) this issue.

- the current way SSL is used provides little to no security at all

- there are several patches available that completely change the way SSL
is used

- these would break/remove the old way, but with little impact as users
on both sides could easily switch to the non-ssl way.

To my mind, if a upstream is dead/stubborn/unwillingly/etc. and IF there
is a patch available, than distros could and should take care on this.
It seems, the Debian Nagios Maintainers are not.

So I guess the best way now is to escalate this to the Security Team.

Comments?

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/20120317/efa800d0/attachment.bin>