| 2016-03-09 17:39:24 |
Michael Peters |
bug |
|
|
added bug |
| 2016-04-25 14:26:11 |
Launchpad Janitor |
nagios-nrpe (Ubuntu): status |
New |
Confirmed |
|
| 2016-04-25 14:57:53 |
Junkern |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756479 |
|
| 2016-10-28 07:48:52 |
Richard Hillmann |
bug |
|
|
added subscriber Richard Hillmann |
| 2016-12-05 00:01:22 |
Bas Couwenberg |
bug task added |
|
nagios-nrpe (Debian) |
|
| 2016-12-05 00:02:50 |
Bas Couwenberg |
nagios-nrpe (Ubuntu): status |
Confirmed |
Invalid |
|
| 2016-12-05 20:20:53 |
Bug Watch Updater |
nagios-nrpe (Debian): status |
Unknown |
Fix Released |
|
| 2017-04-27 21:05:30 |
Jorge Niedbalski |
nagios-nrpe (Ubuntu): status |
Invalid |
New |
|
| 2017-04-27 21:05:43 |
Jorge Niedbalski |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-04-27 21:05:43 |
Jorge Niedbalski |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-04-27 21:05:43 |
Jorge Niedbalski |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-04-27 21:05:43 |
Jorge Niedbalski |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-04-27 21:09:00 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Zesty) |
|
| 2017-04-27 21:09:06 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Yakkety) |
|
| 2017-04-27 21:09:11 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Xenial) |
|
| 2017-04-27 21:09:18 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Trusty) |
|
| 2017-04-27 21:17:37 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2017-04-28 00:15:43 |
Eric Desrochers |
bug task deleted |
nagios-nrpe (Ubuntu Zesty) |
|
|
| 2017-04-28 00:15:48 |
Eric Desrochers |
bug task deleted |
nagios-nrpe (Ubuntu Yakkety) |
|
|
| 2017-04-28 00:15:53 |
Eric Desrochers |
bug task deleted |
nagios-nrpe (Ubuntu Xenial) |
|
|
| 2017-04-28 00:15:57 |
Eric Desrochers |
bug task deleted |
nagios-nrpe (Ubuntu Trusty) |
|
|
| 2017-04-28 02:48:48 |
Eric Desrochers |
tags |
|
sts |
|
| 2017-04-28 06:02:53 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2017-04-28 13:21:29 |
Eric Desrochers |
nagios-nrpe (Ubuntu): status |
New |
Won't Fix |
|
| 2017-04-28 13:23:39 |
Eric Desrochers |
nagios-nrpe (Ubuntu): status |
Won't Fix |
New |
|
| 2017-04-28 13:51:38 |
Launchpad Janitor |
nagios-nrpe (Ubuntu): status |
New |
Confirmed |
|
| 2017-05-02 02:07:56 |
Tyler Hicks |
cve linked |
|
2013-1362 |
|
| 2017-05-02 02:09:06 |
Tyler Hicks |
bug |
|
|
added subscriber Tyler Hicks |
| 2017-05-02 04:56:10 |
Eric Desrochers |
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. |
[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. |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
nominated for series |
|
Ubuntu Yakkety |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Yakkety) |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
nominated for series |
|
Ubuntu Artful |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Artful) |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Xenial) |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-05-02 04:58:49 |
Eric Desrochers |
bug task added |
|
nagios-nrpe (Ubuntu Zesty) |
|
| 2017-05-02 04:59:03 |
Eric Desrochers |
nagios-nrpe (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-05-02 04:59:05 |
Eric Desrochers |
nagios-nrpe (Ubuntu Yakkety): status |
New |
Confirmed |
|
| 2017-05-02 04:59:08 |
Eric Desrochers |
nagios-nrpe (Ubuntu Zesty): status |
New |
Confirmed |
|
| 2017-05-02 05:00:56 |
Eric Desrochers |
description |
[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. |
[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.
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. |
|
| 2017-05-02 05:01:25 |
Eric Desrochers |
description |
[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.
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. |
[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
[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. |
|
| 2017-05-02 05:01:47 |
Eric Desrochers |
nagios-nrpe (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
| 2017-05-02 05:01:49 |
Eric Desrochers |
nagios-nrpe (Ubuntu Yakkety): assignee |
|
Eric Desrochers (slashd) |
|
| 2017-05-02 05:01:51 |
Eric Desrochers |
nagios-nrpe (Ubuntu Zesty): assignee |
|
Eric Desrochers (slashd) |
|
| 2017-05-02 05:01:53 |
Eric Desrochers |
nagios-nrpe (Ubuntu Artful): assignee |
|
Eric Desrochers (slashd) |
|
| 2017-05-02 05:01:57 |
Eric Desrochers |
nagios-nrpe (Ubuntu Artful): importance |
Undecided |
Wishlist |
|
| 2017-05-02 05:02:03 |
Eric Desrochers |
nagios-nrpe (Ubuntu Artful): importance |
Wishlist |
Low |
|
| 2017-05-02 05:02:06 |
Eric Desrochers |
nagios-nrpe (Ubuntu Zesty): importance |
Undecided |
Low |
|
| 2017-05-02 05:02:08 |
Eric Desrochers |
nagios-nrpe (Ubuntu Yakkety): importance |
Undecided |
Low |
|
| 2017-05-02 05:02:10 |
Eric Desrochers |
nagios-nrpe (Ubuntu Xenial): importance |
Undecided |
Low |
|
| 2017-05-02 05:04:32 |
Eric Desrochers |
tags |
sts |
sts sts-sru |
|
| 2017-05-02 05:08:07 |
Eric Desrochers |
description |
[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
[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. |
[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 :
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. |
|
| 2017-05-02 05:11:09 |
Eric Desrochers |
nagios-nrpe (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2017-05-02 05:11:11 |
Eric Desrochers |
nagios-nrpe (Ubuntu Yakkety): status |
Confirmed |
In Progress |
|
| 2017-05-02 05:11:13 |
Eric Desrochers |
nagios-nrpe (Ubuntu Zesty): status |
Confirmed |
In Progress |
|
| 2017-05-02 05:11:15 |
Eric Desrochers |
nagios-nrpe (Ubuntu Artful): status |
Confirmed |
In Progress |
|
| 2017-05-02 12:05:22 |
Eric Desrochers |
description |
[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 :
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. |
[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:
...
Note, after verification :
Xenial, Yakkety and Zesty already has the above CVE point out by Tyler.
* 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 :
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. |
|
| 2017-05-02 12:07:08 |
Eric Desrochers |
description |
[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:
...
Note, after verification :
Xenial, Yakkety and Zesty already has the above CVE point out by Tyler.
* 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 :
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. |
[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 :
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. |
|
| 2017-05-02 12:38:01 |
Eric Desrochers |
description |
[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 :
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. |
[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 :
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/commit/5bf9b2047f8e9a8609c3b95b2e655368765e4dd1
[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. |
|
| 2017-05-02 13:38:00 |
Eric Desrochers |
description |
[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 :
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/commit/5bf9b2047f8e9a8609c3b95b2e655368765e4dd1
[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. |
[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
Note that Artful and Zesty already has the commit mentioned by Tyler :
a/nagios-nrpe-3.0.1/src/nrpe.c:#define NASTY_METACHARS "|`&><'\\[]{};\r\n"
z/nagios-nrpe-3.0.1/src/nrpe.c:#define NASTY_METACHARS "|`&><'\\[]{};\r\n"
Thus, only Xenial and Yakkety requires it.
x/nagios-nrpe-2.15/src/nrpe.c:#define NASTY_METACHARS "|`&><'\"\\[]{};"
y/nagios-nrpe-2.15/src/nrpe.c:#define NASTY_METACHARS "|`&><'\"\\[]{};"
[Other Info]
* CVE-2013-1362 :
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/commit/5bf9b2047f8e9a8609c3b95b2e655368765e4dd1
[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. |
|
| 2017-05-02 14:03:47 |
Eric Desrochers |
attachment added |
|
artful_lp1555258.debdiff https://bugs.launchpad.net/ubuntu/xenial/+source/nagios-nrpe/+bug/1555258/+attachment/4870818/+files/artful_lp1555258.debdiff |
|
| 2017-05-02 14:11:43 |
Eric Desrochers |
nagios-nrpe (Ubuntu Artful): importance |
Low |
Medium |
|
| 2017-05-02 14:11:45 |
Eric Desrochers |
nagios-nrpe (Ubuntu Zesty): importance |
Low |
Medium |
|
| 2017-05-02 14:11:47 |
Eric Desrochers |
nagios-nrpe (Ubuntu Yakkety): importance |
Low |
Medium |
|
| 2017-05-02 14:11:48 |
Eric Desrochers |
nagios-nrpe (Ubuntu Xenial): importance |
Low |
Medium |
|
| 2017-05-02 14:15:07 |
Eric Desrochers |
description |
[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
Note that Artful and Zesty already has the commit mentioned by Tyler :
a/nagios-nrpe-3.0.1/src/nrpe.c:#define NASTY_METACHARS "|`&><'\\[]{};\r\n"
z/nagios-nrpe-3.0.1/src/nrpe.c:#define NASTY_METACHARS "|`&><'\\[]{};\r\n"
Thus, only Xenial and Yakkety requires it.
x/nagios-nrpe-2.15/src/nrpe.c:#define NASTY_METACHARS "|`&><'\"\\[]{};"
y/nagios-nrpe-2.15/src/nrpe.c:#define NASTY_METACHARS "|`&><'\"\\[]{};"
[Other Info]
* CVE-2013-1362 :
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/commit/5bf9b2047f8e9a8609c3b95b2e655368765e4dd1
[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. |
[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 accommodate Ubuntu Nagios users.
* Doug's comment explain well the situation :
https://bugs.launchpad.net/ubuntu/xenial/+source/nagios-nrpe/+bug/1555258/comments/6
[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
Note that Artful and Zesty already has the commit mentioned by Tyler :
a/nagios-nrpe-3.0.1/src/nrpe.c:#define NASTY_METACHARS "|`&><'\\[]{};\r\n"
z/nagios-nrpe-3.0.1/src/nrpe.c:#define NASTY_METACHARS "|`&><'\\[]{};\r\n"
Thus, only Xenial and Yakkety requires it.
x/nagios-nrpe-2.15/src/nrpe.c:#define NASTY_METACHARS "|`&><'\"\\[]{};"
y/nagios-nrpe-2.15/src/nrpe.c:#define NASTY_METACHARS "|`&><'\"\\[]{};"
[Other Info]
* CVE-2013-1362 :
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/commit/5bf9b2047f8e9a8609c3b95b2e655368765e4dd1
[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. |
|
| 2017-05-02 14:59:56 |
Eric Desrochers |
bug |
|
|
added subscriber SRU Verification |
| 2017-05-02 15:00:12 |
Eric Desrochers |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2017-05-02 15:12:50 |
Launchpad Janitor |
nagios-nrpe (Ubuntu Artful): status |
In Progress |
Fix Released |
|
| 2017-05-02 17:21:48 |
Eric Desrochers |
attachment added |
|
zesty_nagiosnrpe_lp1555258.debdiff https://bugs.launchpad.net/ubuntu/xenial/+source/nagios-nrpe/+bug/1555258/+attachment/4870940/+files/zesty_nagiosnrpe_lp1555258.debdiff |
|
| 2017-05-02 17:52:33 |
Eric Desrochers |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2017-05-02 20:12:26 |
Eric Desrochers |
attachment added |
|
zesty_nagiosnrpe_lp1555258_V2.debdiff https://bugs.launchpad.net/ubuntu/yakkety/+source/nagios-nrpe/+bug/1555258/+attachment/4871011/+files/zesty_nagiosnrpe_lp1555258_V2.debdiff |
|
| 2017-05-04 16:22:15 |
Eric Desrochers |
attachment added |
|
xenial_lp1555258.debdiff https://bugs.launchpad.net/ubuntu/xenial/+source/nagios-nrpe/+bug/1555258/+attachment/4871981/+files/xenial_lp1555258.debdiff |
|
| 2017-05-04 18:22:05 |
Brian Murray |
nagios-nrpe (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-05-04 18:22:09 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-05-04 18:22:20 |
Brian Murray |
tags |
sts sts-sru |
sts sts-sru verification-needed |
|
| 2017-05-04 22:22:34 |
Eric Desrochers |
tags |
sts sts-sru verification-needed |
sts sts-sru verification-done-zesty |
|
| 2017-05-08 13:04:01 |
Eric Desrochers |
attachment added |
|
yakkety_lp1555258.debdiff https://bugs.launchpad.net/ubuntu/yakkety/+source/nagios-nrpe/+bug/1555258/+attachment/4873442/+files/yakkety_lp1555258.debdiff |
|
| 2017-05-08 15:58:21 |
Łukasz Zemczak |
nagios-nrpe (Ubuntu Yakkety): status |
In Progress |
Fix Committed |
|
| 2017-05-08 15:58:27 |
Łukasz Zemczak |
tags |
sts sts-sru verification-done-zesty |
sts sts-sru verification-done-zesty verification-needed |
|
| 2017-05-08 15:59:53 |
Łukasz Zemczak |
nagios-nrpe (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-05-08 17:46:03 |
Eric Desrochers |
tags |
sts sts-sru verification-done-zesty verification-needed |
sts-sru verification-done-xenial verification-done-yakkety verification-done-zesty |
|
| 2017-05-11 14:42:07 |
François Blondel |
nagios-nrpe (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-05-11 14:56:25 |
Eric Desrochers |
nagios-nrpe (Ubuntu Xenial): status |
Fix Released |
Fix Committed |
|
| 2017-05-15 16:04:42 |
Launchpad Janitor |
nagios-nrpe (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-05-15 16:04:46 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-05-17 02:47:53 |
Launchpad Janitor |
nagios-nrpe (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-05-17 02:49:25 |
Launchpad Janitor |
nagios-nrpe (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2017-06-02 18:24:41 |
Eric Desrochers |
removed subscriber SRU Verification |
|
|
|
