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

Mon Feb 20 13:05:13 UTC 2012

-------- Original Message  --------
Subject: [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: 547092 at bugs.debian.org
Date: 2012-02-20 13:14
> Hi Alexander.
>
> On Mon, 2012-02-20 at 06:29 +0100, Alexander Wirt wrote:
>> this breaks all existing nrpes
> What do you mean by breaking NRPEs?

https://git.icinga.org/?p=icinga-nrpe.git;a=commit;h=025334c19f252f43c4ae8209ff1eec889908478b

especially, 
https://git.icinga.org/?p=icinga-nrpe.git;a=blobdiff;f=src/nrpe.c;h=1618be253465e3201ca0c988e176727f77abf8fa;hp=f5859b7a0c4c0aea7246a75fdf0d4c712106c68a;hb=025334c19f252f43c4ae8209ff1eec889908478b;hpb=b3eacf64ff33198c300f8ae72c77eedc91095093

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

>
> But even if it does... wouldn't that be better? That SSL is just
> useless, so admins are better off with disabling it altogether.

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.

and with upstream, i do mean the official nagios nrpe project. the 
icinga one is just an unofficial fork, trying to collect various 
community patches, and if worth the squeeze, release as seperate 
version. but this is not yet decided when and where, because there isn't 
any official maintainer (within the icinga project).

>
>> and icinga nrpe is not in a releasable state.
> Just for my personal education :) ... what's the issue about it?

as pointed out previously, read the development tracker, especially the 
issues and the roadmap. there's a reason i'm posting those urls.

>
>
> I mean the current situation is IMHO a bit concerning.
> - Nagios upstream seems to have abandoned this issue.

this isn't news for anyone in the nagios space. can you do better than 
just telling us?

>
> - SSL is activated per default in Debian, which is useless anyway and in
> the worst case gives a wrong feeling of security.

it is not "useless anyway". it just contains the same dh key generated 
on package build. so each revision will contain at least a different dh 
key.
and it is well known to those following bugs and cves that nrpe got 
those issues, but the discussion has not yet reached a level where 
patches would entirely and not breaking fix that issue.
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.

>
> - Severity of this issue is "just" important, IMHO it should be grave
> (http://www.debian.org/Bugs/Developer#severities), which would also
> notify at least those using apt-listbugs.

a package should contain the upstream release source. a package should 
mostly not entirely change the mechanism of a transport layer within the 
source release, even if this is considered a security flaw. a package 
does not mean that the packager him/herself necessary needs to know how 
the upstream release is coded and how to fix bugs within them. and a 
package means that the package maintainer must decide if userprovided 
patches can be seaminglessly integrated into the package, or if he/she 
wants to wait for an upstream decision because of the severity of 
changes introduced by that patch.

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.

i've already put various weekends into the icinga nrpe version and their 
patches, but currently i cannot maintain core+cgi+idoutils+mq and things 
like nrpe/nsca. that will require code, tests, and community feedback.

>
> - Of course one can argue that you cannot do much of an attack with
> NRPE, but people may rely on SSL and think it safe because of it to
> enable argument processing in NRPE

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.

>
>
> Cheers,
> Chris.
>
>
> _______________________________________________
> Pkg-nagios-devel mailing list
> Pkg-nagios-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nagios-devel

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