Nagios NRPE 3.2.1 has Insufficient Filtering because, for example, nasty_metachars interprets \n as the character \ and the character n (not as the \n newline sequence). This can cause command injection. Reference: https://herolab.usd.de/security-advisories/usd-2020-0002/
Created nrpe tracking bugs for this issue: Affects: epel-all [bug 1816805] Affects: fedora-all [bug 1816804]
Statement: Nagios is considered deprecated. Nagios plugins and Nagios server are no longer maintained or supported. Refer following release notes for details: "https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/3.5_release_notes/index". The older version of nrpe which was shipped with Red Hat Gluster Storage does not support v3 packet format.
External References: https://herolab.usd.de/security-advisories/usd-2020-0002/
Mitigation: Disable nasty_metachars and dont_blame_nrpe option inside the NRPE configuration file - /etc/nagios/nrpe.cfg
(In reply to Hardik Vyas from comment #2) > Statement: > > Nagios is considered deprecated. Nagios plugins and Nagios server are no > longer maintained or supported. Refer following release notes for details: > "https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/ > html-single/3.5_release_notes/index". The older version of nrpe which was > shipped with Red Hat Gluster Storage does not support v3 packet format. According to this web page, Nagios/NRPE are not supported to monitor Red Hat Gluster Storage 3.5. Is it supported on any RHEL as monitoring solution? I don't know about any deprecations of Nagios in RHEL. If it's still supported, why this bug has been closed?
I thought this is the master bug to track the Fedora, Red Hat and EPEL packages bugs. Is this the right one to have closed? One particular to gluster should be closed if it is no longer supported by Red Hat, but I don't think the master should be closed as the Fedora and EPEL parts are still affected.
In reply to comment #5: > (In reply to Hardik Vyas from comment #2) > > Statement: > > > > Nagios is considered deprecated. Nagios plugins and Nagios server are no > > longer maintained or supported. Refer following release notes for details: > > "https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/ > > html-single/3.5_release_notes/index". The older version of nrpe which was > > shipped with Red Hat Gluster Storage does not support v3 packet format. > > According to this web page, Nagios/NRPE are not supported to monitor Red Hat > Gluster Storage 3.5. > > Is it supported on any RHEL as monitoring solution? I don't know about any > deprecations of Nagios in RHEL. If it's still supported, why this bug has > been closed? This vulnerability is against NRPE package which is only shipped in Red Hat Gluster Storage, non of the other Red Hat offerings include nrpe package hence other Red Hat products are not listed in affected list of products. In Gluster, nrpe is installed as a dependency for gluster-nagios-addons, once all the nagios dependencies are removed from Gluster channel, nrpe will also be removed which is not maintained currently.
In reply to comment #6: > I thought this is the master bug to track the Fedora, Red Hat and EPEL > packages bugs. Is this the right one to have closed? One particular to > gluster should be closed if it is no longer supported by Red Hat, but I > don't think the master should be closed as the Fedora and EPEL parts are > still affected. For Fedora and EPEL we generally file separate tracker bugs[1][2], so that the progress can be tracked accordingly. We evaluate master bug closure only based on commercial Red Hat products which are later populated on our CVE page. Community projects like Fedora and EPEL are not populated on CVE page. Hence, if none of our products(non-community) are affected we close the CVE as CLOSED:NOTABUG and status of community projects can be tracked separately on their individual tracker bugs as mentioned below. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1816804 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1816805
Thank you for the explanation.