[Pkg-nagios-devel] Bug#547092: Bug#547092: Bug#547092: nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems
Michael Friedrich
michael.friedrich at univie.ac.at
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
More information about the Pkg-nagios-devel
mailing list