Skip to content

Instantly share code, notes, and snippets.

Last active August 29, 2015 13:56
Show Gist options
  • Save azet/8979114 to your computer and use it in GitHub Desktop.
Save azet/8979114 to your computer and use it in GitHub Desktop.
mail regarding security flaws in Nagios NRPE to nagios devel and security lists
Return-Path: <>
Received: from [] ([])
by with ESMTPSA id f45sm8725929eeg.5.2014.
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 13 Feb 2014 08:32:24 -0800 (PST)
Message-ID: <>
Date: Thu, 13 Feb 2014 17:32:25 +0100
From: Aaron Zauner <>
User-Agent: Postbox 3.0.9 (Macintosh/20140129)
MIME-Version: 1.0
Subject: Critical security flaws in Nagios NRPE client/server crypto
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg=pgp-sha1;
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
in CC to: grok full disclosure, bugtraq
Dear Nagios developers,
It's been a couple of years since I've had a look at NRPE, the remote
monitoring agent distributed with Nagios. Back then we've exclusively
used NRPE on unrouted dedicated monitoring vLANS.
I've recently been implementing monitoring with Icinga2 and been looking
up NRPE again. So I read through your source code and "documentation".
Here's my impression of your work.
- Cryptography -
The Encryption is done using a set encryption routine of
AES-256 Bit Encryption using SHA and Anon-DH. This encrypts
all traffic using the NRPE sockets from the client to the server.
This is simply not true.
src/nrpe.c L259 and src/client_check.c L168:
Setting the cipherstring to "ADH" allows for a multitude of possible
cipherstrings, depending on the OpenSSL configuration on the system and
the configuration shipped by the operating system distribution.
Furthermore, a quick peek into the OpenSSL wiki [0] or any textbook [1]
on the subject would have shown you that anonymous diffie hellman does
not provide any kind of authentication, and is thus, vulnerable to
(easily mounted) man-in-the-middle attacks.
src/nrpe.c L256 and src/client_check.c L145:
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
You're excluding SSLv2 and SSLv3, still leaving two broken protocols in
there: TLSv1.0 and TLSv1.1.
Since we are using Anon-DH this allows for an encrypted
SSL/TLS Connection without using pre-generated keys or
certificates. The key generation information used by the
program to dynaically create keys on daemon startup can be found
in the dh.h file in the nrpe src directory. This file was created
using the command:
openssl dhparam -C 512
512bit DH has been broken _in_the_real_world_ for a couple of years.
Current best practices recommend 3k+ [2]. Further more regenerating
diffie-hellman parameters with autotools may not really improve security.=
As to the note on the developer not being sure if there would be
restrictions on the export: Yes. If you live in oppressive regimes there
are restrictions. i.e. for the US of A put a cryptography export notice
The aforementioned implementation of "cryptography" does not provide any
security other than security by obscurity. It's completely absurd and
system administrators without proper knowledge might actually deploy
this, without any warning on the security implications caused by a
fisher-price-my-first-crypto implementation. The first lesson in any
course on cryptography is always =E2=80=9Cdo not implement yourself!=E2=80=
- Code quality -
As with the Nagios core, the overall code quality is just horrendous.
I've not had time to check thoroughly but from just scrolling though I
see a wide variety of format string vulnerabilities and bad coding
- Bashing doesn't help, after all it's FOSS, right? -
I've patched some parts of the code to explicitly exclude anything else
than TLSv1.2 and use a sane default cipher string loaded from a
configuration file. But there's still much work to do to enable
something with low overhead like ECDHE-ECDSA - because, yes, in this
case, for good security you'll need certificate handling and proper
implemented PKI. I'm not sure on how to proceed, I see the following
three options:
=2E) Do nothing and ignore security completely
=2E) Completely remove the mentioned SSL code parts and only point to stu=
=2E) Implement proper PKI with current cryptography and update the projec=
accordingly (I=E2=80=99d help with that - but I=E2=80=99m not sure if tha=
ts even reasonable)
Aaron Zauner
[0] -
[1] -
[1] -
[2] -
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment