In Sudo before 1.8.31, 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. Upstream patch: https://github.com/sudo-project/sudo/commit/fa8ffeb17523494f0e8bb49a25e53635f4509078 References: https://www.sudo.ws/alerts/pwfeedback.html https://www.openwall.com/lists/oss-security/2020/01/30/6
Created sudo tracking bugs for this issue: Affects: fedora-all [bug 1796945]
External References: https://www.sudo.ws/alerts/pwfeedback.html
There's a bug on sudo package when pwfeedback feature is enabled and password is read from a pipe. This happens due to the fact getln() fails to reset the pointer position from the read buffer when a erase character is read. This failure allows an attacker to craft a password input in order to cause sudo to crash, expose data, corrupt data and possibly inject code to be executed.
Created sudo tracking bugs for this issue: Affects: fedora-all [bug 1798531]
Mitigation: Please follow the steps bellow as mitigation: 1. Check the default properties set for sudo by running: ~~~ $ sudo -l [sudo] password for user: Matching Defaults entries for users on localhost: !visiblepw, pwfeedback, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin ~~~ 2. If `pwfeedback` is enabled as shown above, edit your `/etc/sudoers` file, changing the line: ~~~ Defaults pwfeedback ~~~ To: ~~~ Defaults !pwfeedback ~~~ This will disable visual feedback on password typing, making sure the attack is not possible anymore.
A deeper analysis shows the sudo version shipped with RHEL 5 is not affected. More recent versions include a break; statement when write(2) fails to write the backspace character to the output on getln() function and password feedback is enabled. The main issue with that is the fact write(2) will always fail to write to unidirectional pipes thus when facing a VERASE character sudo won't reset back the buffer position pointer in such scenarios, which will subsequently lead to the buffer overflow. This can be observed on sudo version 1.8.0 and above. The commit which introduced the vulnerability seems to be: commit 420db23714ffcab87caa67bae0e3de9f42222cf9 Author: Todd C. Miller <Todd.Miller> Date: Tue Aug 3 11:17:56 2010 -0400 Quiet gcc warnings on glibc systems that use warn_unused_result for write(2) and others. Red Hat Enterprise 5 ships sudo v.1.7.2p1 which still doesn't have this specific behavior. Even if write(2) fails due to unidirectional pipe it still decrease the current pointer position correctly when the termios's VERASE character is found in the password input.
Statement: This flaw can only be exploited if the option `pwfeedback` is enabled in sudo configuration. This option is not enabled by default in any version of Red Hat Enterprise Linux. The sudo packages distributed with Red Hat Enterprise Linux versions are compiled using gcc's stack-protector feature. The "Stack Smashing Protection" may help mitigate code execution attacks for this flaw. Red Hat Enterprise Linux 5 is not affected as it doesn't include the commit which introduced the vulnerability.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:0487 https://access.redhat.com/errata/RHSA-2020:0487
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions Via RHSA-2020:0509 https://access.redhat.com/errata/RHSA-2020:0509
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-18634
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:0540 https://access.redhat.com/errata/RHSA-2020:0540
Per this portal reference (https://access.redhat.com/security/cve/cve-2019-18634), RHEL 6 is listed as affected. Will there be an update made available for RHEL 6? Or was the severity of this issue deemed not high enough to warrant a critical security update?
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2020:0726 https://access.redhat.com/errata/RHSA-2020:0726