** Description changed:
+ [Impact]
+
+ * Debian upstream maintainer decided to compile without
"-enable-command-args" as describe in debian/NEWS file. This decision have the
effect of ignoring the following directive : "dont_blame_nrpe=1" in nrpe.cfg by
not allowing command argument in the deamon.
+ Debian disabled the option because there were concerns about security
problems and that this feature is often used wrong [0] but there are Ubuntu
users out there that know what they're doing and depend on this feature.
+
+ * The expectation is for Ubuntu to deviate from Debian upstream
+ decision to accomodate Ubuntu Nagios users.
+
+ [0] - Debian Bug:
+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756479
+
+ [Test Case]
+
+ * This require a Nagios environment setup (Server and at least 1
+ client)
+
+ * Command example run at server side using "dont_blame_nrpe" set to either 0
(false) or 1 (true) in nrpe.cfg
+ $ sudo -unagios /usr/lib/nagios/plugins/check_nrpe -H x.x.x.x -p 5664 -c
check_procs -a rsyslogd 1 0
+ CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for
error messages.
+
+ May 1 20:20:06 nonrotatable-niki nrpe[83523]: Connection from 10.189.69.52
port 43186
+ May 1 20:20:06 nonrotatable-niki nrpe[83523]: Host address is in
allowed_hosts
+ May 1 20:20:06 nonrotatable-niki nrpe[83523]: Handling the connection...
+ ==> May 1 20:20:06 nonrotatable-niki nrpe[83523]: Error: Request contained
command arguments!
+ ==> May 1 20:20:06 nonrotatable-niki nrpe[83523]: Client request was
invalid, bailing out..
+
+ [Regression Potential]
+
+ * This update enables the command-args (at compile time) support in nrpe by
NOT ignoring option "dont_blame_nrpe=1" IFF set manually.
+ Note that by default, the option is DISABLE in the configuration file
(nrpe.cfg) : "dont_blame_nrpe=0".
+
+ * For users using the default value "dont_blame_nrpe=0", so no behavioural
change. With regard to the risk, I would say it is LOW.
+ The option is disable by default meaning that it doesn't introduce any
security risk for users that doesn't rely on this feature.
+ But it doesn't prevent the risk that non-experimented users enable the
option without considering all the security risk aspects.
+
+ * For users choosing to manually enable this option, the risk is HIGHER, but
we assume that before enabling this option the users are considering the PROS
and CONS.
+
+ * Deviating from Debian upstream for that particular case will allow to
unblock experimented Ubuntu users (who know what they are doing) of nrpe to
make the choice for themselves whether to
+ accept the security risks that the feature involve by manually enabling
command-args in nrpe.cfg or not.
+
+ * Canonical Security team feedbacks :
+
https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258/comments/9
+
+ ...
+ If this feature is enabled in an SRU, the upload must include the fix for
CVE-2013-1362:
+ ...
+
+ * COMMAND ARGUMENTS
+ NRPE 2.0 includes the ability for clients to supply arguments to commands
which should be run. Please note that this feature should be considered a
security risk, and you should only use it if you know what you're doing!
+
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
+
+
+ [Other Info]
+
+
+ * CVE-2013-1362 :
+
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
+
+
+ [Original Description]
+
Ubuntu 15.10 (upgraded from 12.04)
Have tried a full purged removal of nagios-nrpe-server and reinstall
however the "dont_blame_nrpe=1" setting in nrpe.cfg is still being
ignored.
/var/log/syslog reports:
Mar 9 12:33:58 myhost nrpe[17153]: Error: Request contained command
arguments!
Mar 9 12:33:58 myhost nrpe[17153]: Client request was invalid, bailing out...
All checks of this box have stopped working since the upgrade and I
would like to get to the bottom of why NRPE is not honoring my request
to allow command arguments.
** Also affects: nagios-nrpe (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Also affects: nagios-nrpe (Ubuntu Artful)
Importance: Undecided
Status: Confirmed
** Also affects: nagios-nrpe (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: nagios-nrpe (Ubuntu Zesty)
Importance: Undecided
Status: New
** Changed in: nagios-nrpe (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: nagios-nrpe (Ubuntu Yakkety)
Status: New => Confirmed
** Changed in: nagios-nrpe (Ubuntu Zesty)
Status: New => Confirmed
** Description changed:
[Impact]
- * Debian upstream maintainer decided to compile without
"-enable-command-args" as describe in debian/NEWS file. This decision have the
effect of ignoring the following directive : "dont_blame_nrpe=1" in nrpe.cfg by
not allowing command argument in the deamon.
- Debian disabled the option because there were concerns about security
problems and that this feature is often used wrong [0] but there are Ubuntu
users out there that know what they're doing and depend on this feature.
+ * Debian upstream maintainer decided to compile without
"-enable-command-args" as describe in debian/NEWS file. This decision have the
effect of ignoring the following directive : "dont_blame_nrpe=1" in nrpe.cfg by
not allowing command argument in the deamon.
+ Debian disabled the option because there were concerns about security
problems and that this feature is often used wrong [0] but there are Ubuntu
users out there that know what they're doing and depend on this feature.
- * The expectation is for Ubuntu to deviate from Debian upstream
+ * The expectation is for Ubuntu to deviate from Debian upstream
decision to accomodate Ubuntu Nagios users.
[0] - Debian Bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756479
[Test Case]
- * This require a Nagios environment setup (Server and at least 1
+ * This require a Nagios environment setup (Server and at least 1
client)
- * Command example run at server side using "dont_blame_nrpe" set to either 0
(false) or 1 (true) in nrpe.cfg
+ * Command example run at server side using "dont_blame_nrpe" set to either 0
(false) or 1 (true) in nrpe.cfg
$ sudo -unagios /usr/lib/nagios/plugins/check_nrpe -H x.x.x.x -p 5664 -c
check_procs -a rsyslogd 1 0
CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for
error messages.
- May 1 20:20:06 nonrotatable-niki nrpe[83523]: Connection from 10.189.69.52
port 43186
- May 1 20:20:06 nonrotatable-niki nrpe[83523]: Host address is in
allowed_hosts
- May 1 20:20:06 nonrotatable-niki nrpe[83523]: Handling the connection...
- ==> May 1 20:20:06 nonrotatable-niki nrpe[83523]: Error: Request contained
command arguments!
- ==> May 1 20:20:06 nonrotatable-niki nrpe[83523]: Client request was
invalid, bailing out..
+ Server logs:
+ nrpe[83523]: Connection from y.y.y.y port 43186
+ nrpe[83523]: Host address is in allowed_hosts
+ nrpe[83523]: Handling the connection...
+ ==> nrpe[83523]: Error: Request contained command arguments!
+ ==> nrpe[83523]: Client request was invalid, bailing out..
[Regression Potential]
- * This update enables the command-args (at compile time) support in nrpe by
NOT ignoring option "dont_blame_nrpe=1" IFF set manually.
- Note that by default, the option is DISABLE in the configuration file
(nrpe.cfg) : "dont_blame_nrpe=0".
+ * This update enables the command-args (at compile time) support in nrpe by
NOT ignoring option "dont_blame_nrpe=1" IFF set manually.
+ Note that by default, the option is DISABLE in the configuration file
(nrpe.cfg) : "dont_blame_nrpe=0".
- * For users using the default value "dont_blame_nrpe=0", so no behavioural
change. With regard to the risk, I would say it is LOW.
- The option is disable by default meaning that it doesn't introduce any
security risk for users that doesn't rely on this feature.
- But it doesn't prevent the risk that non-experimented users enable the
option without considering all the security risk aspects.
-
- * For users choosing to manually enable this option, the risk is HIGHER, but
we assume that before enabling this option the users are considering the PROS
and CONS.
+ * For users using the default value "dont_blame_nrpe=0", so no behavioural
change. With regard to the risk, I would say it is LOW.
+ The option is disable by default meaning that it doesn't introduce any
security risk for users that doesn't rely on this feature.
+ But it doesn't prevent the risk that non-experimented users enable the
option without considering all the security risk aspects.
- * Deviating from Debian upstream for that particular case will allow to
unblock experimented Ubuntu users (who know what they are doing) of nrpe to
make the choice for themselves whether to
- accept the security risks that the feature involve by manually enabling
command-args in nrpe.cfg or not.
+ * For users choosing to manually enable this option, the risk is
+ HIGHER, but we assume that before enabling this option the users are
+ considering the PROS and CONS.
- * Canonical Security team feedbacks :
-
https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258/comments/9
+ * Deviating from Debian upstream for that particular case will allow to
unblock experimented Ubuntu users (who know what they are doing) of nrpe to
make the choice for themselves whether to
+ accept the security risks that the feature involve by manually enabling
command-args in nrpe.cfg or not.
- ...
- If this feature is enabled in an SRU, the upload must include the fix for
CVE-2013-1362:
- ...
+ * Canonical Security team feedbacks :
+
https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258/comments/9
- * COMMAND ARGUMENTS
- NRPE 2.0 includes the ability for clients to supply arguments to commands
which should be run. Please note that this feature should be considered a
security risk, and you should only use it if you know what you're doing!
-
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
+ ...
+ If this feature is enabled in an SRU, the upload must include the fix for
CVE-2013-1362:
+ ...
+ * COMMAND ARGUMENTS
+ NRPE 2.0 includes the ability for clients to supply arguments to commands
which should be run. Please note that this feature should be considered a
security risk, and you should only use it if you know what you're doing!
+
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
[Other Info]
-
* CVE-2013-1362 :
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
-
[Original Description]
Ubuntu 15.10 (upgraded from 12.04)
Have tried a full purged removal of nagios-nrpe-server and reinstall
however the "dont_blame_nrpe=1" setting in nrpe.cfg is still being
ignored.
/var/log/syslog reports:
Mar 9 12:33:58 myhost nrpe[17153]: Error: Request contained command
arguments!
Mar 9 12:33:58 myhost nrpe[17153]: Client request was invalid, bailing out...
All checks of this box have stopped working since the upgrade and I
would like to get to the bottom of why NRPE is not honoring my request
to allow command arguments.
** Description changed:
[Impact]
* Debian upstream maintainer decided to compile without
"-enable-command-args" as describe in debian/NEWS file. This decision have the
effect of ignoring the following directive : "dont_blame_nrpe=1" in nrpe.cfg by
not allowing command argument in the deamon.
Debian disabled the option because there were concerns about security
problems and that this feature is often used wrong [0] but there are Ubuntu
users out there that know what they're doing and depend on this feature.
* The expectation is for Ubuntu to deviate from Debian upstream
decision to accomodate Ubuntu Nagios users.
[0] - Debian Bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756479
[Test Case]
* This require a Nagios environment setup (Server and at least 1
client)
* Command example run at server side using "dont_blame_nrpe" set to either 0
(false) or 1 (true) in nrpe.cfg
- $ sudo -unagios /usr/lib/nagios/plugins/check_nrpe -H x.x.x.x -p 5664 -c
check_procs -a rsyslogd 1 0
+ $ /usr/lib/nagios/plugins/check_nrpe -H x.x.x.x -p 5664 -c check_procs -a
rsyslogd 1 0
CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for
error messages.
Server logs:
nrpe[83523]: Connection from y.y.y.y port 43186
nrpe[83523]: Host address is in allowed_hosts
nrpe[83523]: Handling the connection...
==> nrpe[83523]: Error: Request contained command arguments!
==> nrpe[83523]: Client request was invalid, bailing out..
[Regression Potential]
* This update enables the command-args (at compile time) support in nrpe by
NOT ignoring option "dont_blame_nrpe=1" IFF set manually.
Note that by default, the option is DISABLE in the configuration file
(nrpe.cfg) : "dont_blame_nrpe=0".
* For users using the default value "dont_blame_nrpe=0", so no behavioural
change. With regard to the risk, I would say it is LOW.
The option is disable by default meaning that it doesn't introduce any
security risk for users that doesn't rely on this feature.
But it doesn't prevent the risk that non-experimented users enable the
option without considering all the security risk aspects.
* For users choosing to manually enable this option, the risk is
HIGHER, but we assume that before enabling this option the users are
considering the PROS and CONS.
* Deviating from Debian upstream for that particular case will allow to
unblock experimented Ubuntu users (who know what they are doing) of nrpe to
make the choice for themselves whether to
accept the security risks that the feature involve by manually enabling
command-args in nrpe.cfg or not.
* Canonical Security team feedbacks :
https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258/comments/9
...
If this feature is enabled in an SRU, the upload must include the fix for
CVE-2013-1362:
...
* COMMAND ARGUMENTS
NRPE 2.0 includes the ability for clients to supply arguments to commands
which should be run. Please note that this feature should be considered a
security risk, and you should only use it if you know what you're doing!
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
[Other Info]
* CVE-2013-1362 :
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
[Original Description]
Ubuntu 15.10 (upgraded from 12.04)
Have tried a full purged removal of nagios-nrpe-server and reinstall
however the "dont_blame_nrpe=1" setting in nrpe.cfg is still being
ignored.
/var/log/syslog reports:
Mar 9 12:33:58 myhost nrpe[17153]: Error: Request contained command
arguments!
Mar 9 12:33:58 myhost nrpe[17153]: Client request was invalid, bailing out...
All checks of this box have stopped working since the upgrade and I
would like to get to the bottom of why NRPE is not honoring my request
to allow command arguments.
** Changed in: nagios-nrpe (Ubuntu Xenial)
Assignee: (unassigned) => Eric Desrochers (slashd)
** Changed in: nagios-nrpe (Ubuntu Yakkety)
Assignee: (unassigned) => Eric Desrochers (slashd)
** Changed in: nagios-nrpe (Ubuntu Zesty)
Assignee: (unassigned) => Eric Desrochers (slashd)
** Changed in: nagios-nrpe (Ubuntu Artful)
Assignee: (unassigned) => Eric Desrochers (slashd)
** Changed in: nagios-nrpe (Ubuntu Artful)
Importance: Undecided => Wishlist
** Changed in: nagios-nrpe (Ubuntu Artful)
Importance: Wishlist => Low
** Changed in: nagios-nrpe (Ubuntu Zesty)
Importance: Undecided => Low
** Changed in: nagios-nrpe (Ubuntu Yakkety)
Importance: Undecided => Low
** Changed in: nagios-nrpe (Ubuntu Xenial)
Importance: Undecided => Low
** Tags added: sts-sru
** Description changed:
[Impact]
* Debian upstream maintainer decided to compile without
"-enable-command-args" as describe in debian/NEWS file. This decision have the
effect of ignoring the following directive : "dont_blame_nrpe=1" in nrpe.cfg by
not allowing command argument in the deamon.
Debian disabled the option because there were concerns about security
problems and that this feature is often used wrong [0] but there are Ubuntu
users out there that know what they're doing and depend on this feature.
* The expectation is for Ubuntu to deviate from Debian upstream
decision to accomodate Ubuntu Nagios users.
[0] - Debian Bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756479
[Test Case]
* This require a Nagios environment setup (Server and at least 1
client)
* Command example run at server side using "dont_blame_nrpe" set to either 0
(false) or 1 (true) in nrpe.cfg
$ /usr/lib/nagios/plugins/check_nrpe -H x.x.x.x -p 5664 -c check_procs -a
rsyslogd 1 0
CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for
error messages.
Server logs:
nrpe[83523]: Connection from y.y.y.y port 43186
nrpe[83523]: Host address is in allowed_hosts
nrpe[83523]: Handling the connection...
==> nrpe[83523]: Error: Request contained command arguments!
==> nrpe[83523]: Client request was invalid, bailing out..
[Regression Potential]
* This update enables the command-args (at compile time) support in nrpe by
NOT ignoring option "dont_blame_nrpe=1" IFF set manually.
Note that by default, the option is DISABLE in the configuration file
(nrpe.cfg) : "dont_blame_nrpe=0".
* For users using the default value "dont_blame_nrpe=0", so no behavioural
change. With regard to the risk, I would say it is LOW.
The option is disable by default meaning that it doesn't introduce any
security risk for users that doesn't rely on this feature.
But it doesn't prevent the risk that non-experimented users enable the
option without considering all the security risk aspects.
* For users choosing to manually enable this option, the risk is
HIGHER, but we assume that before enabling this option the users are
considering the PROS and CONS.
* Deviating from Debian upstream for that particular case will allow to
unblock experimented Ubuntu users (who know what they are doing) of nrpe to
make the choice for themselves whether to
accept the security risks that the feature involve by manually enabling
command-args in nrpe.cfg or not.
* Canonical Security team feedbacks :
https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258/comments/9
...
If this feature is enabled in an SRU, the upload must include the fix for
CVE-2013-1362:
...
* COMMAND ARGUMENTS
NRPE 2.0 includes the ability for clients to supply arguments to commands
which should be run. Please note that this feature should be considered a
security risk, and you should only use it if you know what you're doing!
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
[Other Info]
* CVE-2013-1362 :
-
https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md#command-arguments
+
+ Incomplete blacklist vulnerability in nrpc.c in Nagios Remote Plug-In
+ Executor (NRPE) before 2.14 might allow remote attackers to execute
+ arbitrary shell commands via "$()" shell metacharacters, which are
+ processed by bash.
+
+ https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md
+ #command-arguments
[Original Description]
Ubuntu 15.10 (upgraded from 12.04)
Have tried a full purged removal of nagios-nrpe-server and reinstall
however the "dont_blame_nrpe=1" setting in nrpe.cfg is still being
ignored.
/var/log/syslog reports:
Mar 9 12:33:58 myhost nrpe[17153]: Error: Request contained command
arguments!
Mar 9 12:33:58 myhost nrpe[17153]: Client request was invalid, bailing out...
All checks of this box have stopped working since the upgrade and I
would like to get to the bottom of why NRPE is not honoring my request
to allow command arguments.
** Changed in: nagios-nrpe (Ubuntu Xenial)
Status: Confirmed => In Progress
** Changed in: nagios-nrpe (Ubuntu Yakkety)
Status: Confirmed => In Progress
** Changed in: nagios-nrpe (Ubuntu Zesty)
Status: Confirmed => In Progress
** Changed in: nagios-nrpe (Ubuntu Artful)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1555258
Title:
Request contained command arguments
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/1555258/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
