In Sudo through 1.8.29, the fact that a user has been blocked (e.g., by using the ! character in the shadow file instead of a password hash) is not considered, allowing an attacker (who has access to a Runas ALL sudoer account) to impersonate any blocked user. NOTE: The software maintainer believes that this CVE is not valid. Disabling local password authentication for a user is not the same as disabling all access to that user--the user may still be able to login via other means (ssh key, kerberos, etc). Both the Linux shadow(5) and passwd(1) manuals are clear on this. Indeed it is a valid use case to have local accounts that are _only_ accessible via sudo and that cannot be logged into with a password. Sudo 1.8.30 added an optional setting to check the _shell_ of the target user (not the encrypted password!) against the contents of /etc/shells but that is not the same thing as preventing access to users with an invalid password hash

The remote Redhat Enterprise Linux 8 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2020:1804 advisory.

  - sudo: attacker with access to a Runas ALL sudoer account can impersonate a nonexistent user     (CVE-2019-19232)

  - sudo: by using ! character in the shadow file instead of a password hash can access to a run as all sudoer     account (CVE-2019-19234)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

According to the versions of the sudo package installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

  - In Sudo before 1.8.26, if pwfeedback is enabled in     /etc/sudoers, users can trigger a stack-based buffer     overflow in the privileged sudo process. (pwfeedback is     a default setting in Linux Mint and elementary OS     however, it is NOT the default for upstream and many     other packages, and would exist only if enabled by an     administrator.) The attacker needs to deliver a long     string to the stdin of getln() in     tgetpass.c.(CVE-2019-18634)

  - In Sudo through 1.8.29, an attacker with access to a     Runas ALL sudoer account can impersonate a nonexistent     user by invoking sudo with a numeric uid that is not     associated with any user.(CVE-2019-19232)

  - In Sudo through 1.8.29, the fact that a user has been     blocked (e.g., by using the ! character in the shadow     file instead of a password hash) is not considered,     allowing an attacker (who has access to a Runas ALL     sudoer account) to impersonate any blocked     user.(CVE-2019-19234)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the sudo package installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

  - ** DISPUTED ** In Sudo through 1.8.29, the fact that a     user has been blocked (e.g., by using the ! character     in the shadow file instead of a password hash) is not     considered, allowing an attacker (who has access to a     Runas ALL sudoer account) to impersonate any blocked     user. NOTE: The software maintainer believes that this     CVE is not valid. Disabling local password     authentication for a user is not the same as disabling     all access to that user--the user may still be able to     login via other means (ssh key, kerberos, etc). Both     the Linux shadow(5) and passwd(1) manuals are clear on     this. Indeed it is a valid use case to have local     accounts that are _only_ accessible via sudo and that     cannot be logged into with a password. Sudo 1.8.30     added an optional setting to check the _shell_ of the     target user (not the encrypted password!) against the     contents of /etc/shells but that is not the same thing     as preventing access to users with an invalid password     hash.(CVE-2019-19234)

  - ** DISPUTED ** In Sudo through 1.8.29, an attacker with     access to a Runas ALL sudoer account can impersonate a     nonexistent user by invoking sudo with a numeric uid     that is not associated with any user. NOTE: The     software maintainer believes that this is not a     vulnerability because running a command via sudo as a     user not present in the local password database is an     intentional feature. Because this behavior surprised     some users, sudo 1.8.30 introduced an option to     enable/disable this behavior with the default being     disabled. However, this does not change the fact that     sudo was behaving as intended, and as documented, in     earlier versions.(CVE-2019-19232)

  - In Sudo before 1.8.26, if pwfeedback is enabled in     /etc/sudoers, users can trigger a stack-based buffer     overflow in the privileged sudo process. (pwfeedback is     a default setting in Linux Mint and elementary OS     however, it is NOT the default for upstream and many     other packages, and would exist only if enabled by an     administrator.) The attacker needs to deliver a long     string to the stdin of getln() in     tgetpass.c.(CVE-2019-18634)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the sudo package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - ** DISPUTED ** In Sudo through 1.8.29, an attacker with     access to a Runas ALL sudoer account can impersonate a     nonexistent user by invoking sudo with a numeric uid     that is not associated with any user. NOTE: The     software maintainer believes that this is not a     vulnerability because running a command via sudo as a     user not present in the local password database is an     intentional feature. Because this behavior surprised     some users, sudo 1.8.30 introduced an option to     enable/disable this behavior with the default being     disabled. However, this does not change the fact that     sudo was behaving as intended, and as documented, in     earlier versions.(CVE-2019-19232)

  - ** DISPUTED ** In Sudo through 1.8.29, the fact that a     user has been blocked (e.g., by using the ! character     in the shadow file instead of a password hash) is not     considered, allowing an attacker (who has access to a     Runas ALL sudoer account) to impersonate any blocked     user. NOTE: The software maintainer believes that this     CVE is not valid. Disabling local password     authentication for a user is not the same as disabling     all access to that user--the user may still be able to     login via other means (ssh key, kerberos, etc). Both     the Linux shadow(5) and passwd(1) manuals are clear on     this. Indeed it is a valid use case to have local     accounts that are _only_ accessible via sudo and that     cannot be logged into with a password. Sudo 1.8.30     added an optional setting to check the _shell_ of the     target user (not the encrypted password!) against the     contents of /etc/shells but that is not the same thing     as preventing access to users with an invalid password     hash.(CVE-2019-19234)

  - In Sudo before 1.8.26, if pwfeedback is enabled in     /etc/sudoers, users can trigger a stack-based buffer     overflow in the privileged sudo process. (pwfeedback is     a default setting in Linux Mint and elementary OS     however, it is NOT the default for upstream and many     other packages, and would exist only if enabled by an     administrator.) The attacker needs to deliver a long     string to the stdin of getln() in     tgetpass.c.(CVE-2019-18634)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the sudo package installed, the EulerOS Virtualization for ARM 64 installation on the remote host is affected by the following vulnerabilities :

  - In PHP before 5.6.28 and 7.x before 7.0.13, incorrect     handling of various URI components in the URL parser     could be used by attackers to bypass hostname-specific     URL checks, as demonstrated by     evil.example.com:80#@good.example.com/ and     evil.example.com:80?@good.example.com/ inputs to the     parse_url function (implemented in the php_url_parse_ex     function in ext/standard/url.c).(CVE-2019-19234)

  - In Sudo through 1.8.29, the fact that a user has been     blocked (e.g., by using the ! character in the shadow     file instead of a password hash) is not considered,     allowing an attacker (who has access to a Runas ALL     sudoer account) to impersonate any blocked     user.(CVE-2019-19232)

  - In Sudo before 1.8.26, if pwfeedback is enabled in     /etc/sudoers, users can trigger a stack-based buffer     overflow in the privileged sudo process. (pwfeedback is     a default setting in Linux Mint and elementary OS     however, it is NOT the default for upstream and many     other packages, and would exist only if enabled by an     administrator.) The attacker needs to deliver a long     string to the stdin of getln() in     tgetpass.c.(CVE-2019-18634)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the sudo package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - In Sudo through 1.8.29, an attacker with access to a     Runas ALL sudoer account can impersonate a nonexistent     user by invoking sudo with a numeric uid that is not     associated with any user. NOTE: The software maintainer     believes that this is not a vulnerability because     running a command via sudo as a user not present in the     local password database is an intentional feature.
    Because this behavior surprised some users, sudo 1.8.30     introduced an option to enable/disable this behavior     with the default being disabled. However, this does not     change the fact that sudo was behaving as intended, and     as documented, in earlier versions.(CVE-2019-19232)

  - In Sudo through 1.8.29, the fact that a user has been     blocked (e.g., by using the ! character in the shadow     file instead of a password hash) is not considered,     allowing an attacker (who has access to a Runas ALL     sudoer account) to impersonate any blocked user. NOTE:
    The software maintainer believes that this CVE is not     valid. Disabling local password authentication for a     user is not the same as disabling all access to that     user--the user may still be able to login via other     means (ssh key, kerberos, etc). Both the Linux     shadow(5) and passwd(1) manuals are clear on this.
    Indeed it is a valid use case to have local accounts     that are _only_ accessible via sudo and that cannot be     logged into with a password. Sudo 1.8.30 added an     optional setting to check the _shell_ of the target     user (not the encrypted password!) against the contents     of /etc/shells but that is not the same thing as     preventing access to users with an invalid password     hash.(CVE-2019-19234)

  - In Sudo before 1.8.26, if pwfeedback is enabled in     /etc/sudoers, users can trigger a stack-based buffer     overflow in the privileged sudo process. (pwfeedback is     a default setting in Linux Mint and elementary OS     however, it is NOT the default for upstream and many     other packages, and would exist only if enabled by an     administrator.) The attacker needs to deliver a long     string to the stdin of getln() in     tgetpass.c.(CVE-2019-18634)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the sudo package installed, the EulerOS Virtualization for ARM 64 installation on the remote host is affected by the following vulnerabilities :

  - ** DISPUTED ** In Sudo through 1.8.29, the fact that a     user has been blocked (e.g., by using the ! character     in the shadow file instead of a password hash) is not     considered, allowing an attacker (who has access to a     Runas ALL sudoer account) to impersonate any blocked     user. NOTE: The software maintainer believes that this     CVE is not valid. Disabling local password     authentication for a user is not the same as disabling     all access to that user--the user may still be able to     login via other means (ssh key, kerberos, etc). Both     the Linux shadow(5) and passwd(1) manuals are clear on     this. Indeed it is a valid use case to have local     accounts that are _only_ accessible via sudo and that     cannot be logged into with a password. Sudo 1.8.30     added an optional setting to check the _shell_ of the     target user (not the encrypted password!) against the     contents of /etc/shells but that is not the same thing     as preventing access to users with an invalid password     hash.(CVE-2019-19234)

  - ** DISPUTED ** In Sudo through 1.8.29, an attacker with     access to a Runas ALL sudoer account can impersonate a     nonexistent user by invoking sudo with a numeric uid     that is not associated with any user. NOTE: The     software maintainer believes that this is not a     vulnerability because running a command via sudo as a     user not present in the local password database is an     intentional feature. Because this behavior surprised     some users, sudo 1.8.30 introduced an option to     enable/disable this behavior with the default being     disabled. However, this does not change the fact that     sudo was behaving as intended, and as documented, in     earlier versions.(CVE-2019-19232)

  - In Sudo before 1.8.26, if pwfeedback is enabled in     /etc/sudoers, users can trigger a stack-based buffer     overflow in the privileged sudo process. (pwfeedback is     a default setting in Linux Mint and elementary OS     however, it is NOT the default for upstream and many     other packages, and would exist only if enabled by an     administrator.) The attacker needs to deliver a long     string to the stdin of getln() in     tgetpass.c.(CVE-2019-18634)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

- update to latest development version 1.9.0b1

  - added sudo_logsrvd and sudo_sendlog to files and their     appropriate man pages Resolves: rhbz#1787823

  - Stack based buffer overflow in when pwfeedback is     enabled Resolves: rhbz#1796945

  - fixes: CVE-2019-18634 

  - By using ! character in the shadow file instead of a     password hash can access to a run as all sudoer account     Resolves: rhbz#1786709

  - fixes CVE-2019-19234

  - attacker with access to a Runas ALL sudoer account can     impersonate a nonexistent user Resolves: rhbz#1786705

  - fixes CVE-2019-19232

  - setrlimit(RLIMIT_CORE): Operation not permitted warning     message fix Resolves: rhbz#1773148

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website.
Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the sudo package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - In Sudo before 1.8.26, if pwfeedback is enabled in     /etc/sudoers, users can trigger a stack-based buffer     overflow in the privileged sudo process. (pwfeedback is     a default setting in Linux Mint and elementary OS     however, it is NOT the default for upstream and many     other packages, and would exist only if enabled by an     administrator.) The attacker needs to deliver a long     string to the stdin of getln() in     tgetpass.c.(CVE-2019-18634)

  - ** DISPUTED ** In Sudo through 1.8.29, an attacker with     access to a Runas ALL sudoer account can impersonate a     nonexistent user by invoking sudo with a numeric uid     that is not associated with any user. NOTE: The     software maintainer believes that this is not a     vulnerability because running a command via sudo as a     user not present in the local password database is an     intentional feature. Because this behavior surprised     some users, sudo 1.8.30 introduced an option to     enable/disable this behavior with the default being     disabled. However, this does not change the fact that     sudo was behaving as intended, and as documented, in     earlier versions.(CVE-2019-19232)

  - ** DISPUTED ** In Sudo through 1.8.29, the fact that a     user has been blocked (e.g., by using the ! character     in the shadow file instead of a password hash) is not     considered, allowing an attacker (who has access to a     Runas ALL sudoer account) to impersonate any blocked     user. NOTE: The software maintainer believes that this     CVE is not valid. Disabling local password     authentication for a user is not the same as disabling     all access to that user--the user may still be able to     login via other means (ssh key, kerberos, etc). Both     the Linux shadow(5) and passwd(1) manuals are clear on     this. Indeed it is a valid use case to have local     accounts that are _only_ accessible via sudo and that     cannot be logged into with a password. Sudo 1.8.30     added an optional setting to check the _shell_ of the     target user (not the encrypted password!) against the     contents of /etc/shells but that is not the same thing     as preventing access to users with an invalid password     hash.(CVE-2019-19234)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

An update of the sudo package has been released.

ID	Name	Product	Family	Severity
143004	RHEL 8 : sudo (RHSA-2020:1804)	Nessus	Red Hat Local Security Checks	high
141722	EulerOS Virtualization 3.0.2.2 : sudo (EulerOS-SA-2020-2196)	Nessus	Huawei Local Security Checks	high
138004	EulerOS Virtualization 3.0.6.0 : sudo (EulerOS-SA-2020-1785)	Nessus	Huawei Local Security Checks	high
137504	EulerOS 2.0 SP2 : sudo (EulerOS-SA-2020-1662)	Nessus	Huawei Local Security Checks	high
136267	EulerOS Virtualization for ARM 64 3.0.2.0 : sudo (EulerOS-SA-2020-1564)	Nessus	Huawei Local Security Checks	high
135564	EulerOS 2.0 SP3 : sudo (EulerOS-SA-2020-1435)	Nessus	Huawei Local Security Checks	high
135136	EulerOS Virtualization for ARM 64 3.0.6.0 : sudo (EulerOS-SA-2020-1349)	Nessus	Huawei Local Security Checks	high
134253	Fedora 31 : sudo (2020-8b563bc5f4)	Nessus	Fedora Local Security Checks	high
134015	EulerOS 2.0 SP8 : sudo (EulerOS-SA-2020-1181)	Nessus	Huawei Local Security Checks	high
133936	EulerOS 2.0 SP5 : sudo (EulerOS-SA-2020-1135)	Nessus	Huawei Local Security Checks	high
132985	Photon OS 1.0: Sudo PHSA-2020-1.0-0264	Nessus	PhotonOS Local Security Checks	high

Detections

Analytics

CVE-2019-19234

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high