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

Mon Feb 20 18:49:00 UTC 2012

-------- Original Message  --------
Subject: Re: [Pkg-nagios-devel] Bug#547092: Bug#547092: 
nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian 
systems
From: Christoph Anton Mitterer <calestyo at scientia.net>
To: Michael Friedrich <michael.friedrich at univie.ac.at>
Date: 2012-02-20 15:31
> 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.
<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>

>
>
>>> 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.

<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>

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?

>
> 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?

have you ever actually tried that patch you are referring to, like you 
posted the url to?

>
>
>> 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.

LOL. probably you are working on the wrong support channels (if so). i 
know a lot users, who resist my advisories to use packages instead.

> And still, you'd have one shared secret for the whole cluster.

depending on the install method. you cannot guess on internal deployment 
mechanisms, that's merely different for each and everyone.

>
>
>> 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?

not yet. that's why you can see the git, the dev tracker, and a release 
target. but not a date nor a possible roadmap itsself.

>
> That would be bad of course :-(

sure. but if there are no maintainers who like to invest some of their 
time, it will be like that. i'll be willing to share my knowledge on 
what i've already done with it (as well as the others who provided 
patches), but then it's up to the community for now.everyone's invited 
to contribute in productive way...

>
>
>> 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.

that's still only one way to go as those patches suggest. there might be 
other ways as well (see the infamous "dont_blame_nrpe" feature. you will 
be even more shocked, when you analyse that in deep (and find possibly 
bugs on command parsing and injections *cough*).

>
> 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.

see above, especially on the protocol note.

>
>
>> 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 in person have never asked ... so far the least i haven't seen a 
question of yours on nagios-devel lists or the nrpe bug tracker.

>
>
>> 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...

as mentioned previously, behavior changing patches will make packagers 
life hard, even harder than an actual fork keeping updated. and yes, 
integrating such a patch will most likely be a "fork" of the upstream 
releases.

>
> 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.

if you reduce the discussion level a bit (the current one is a bit 
annoying telling things we already know), and just focus on the problem 
and code, i'd love to see some input on the dev tracker. but to be fair, 
you should try it at least once on nagios-devel mailinglists, if it's 
really /dev/null or just a flamewar.

kind regards,
michael

>
>
> Cheers,
> Chris.

-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:  michael.friedrich at univie.ac.at
phone:  +43 1 4277 14359
mobile: +43 664 60277 14359
fax:    +43 1 4277 14338
web:    http://www.univie.ac.at/zid
         http://www.aco.net

Lead Icinga Core Developer
http://www.icinga.org