Sudo has issued an advisory today (January 30): https://www.sudo.ws/alerts/pwfeedback.html https://www.openwall.com/lists/oss-security/2020/01/30/6 The issue is fixed upstream in 1.8.31, and the commit that fixed it is linked in the message above. https://www.sudo.ws/stable.html#1.8.31 Mageia does not use pwfeedback in its default configuration, so only systems that have enabled this are affected.
There is no registered nor evident maintainer for 'sudo', so assigning this globally.
Assignee: bugsquad => pkg-bugs
Suggested advisory: ======================== The updated packages fix a security vulnerability: 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. (CVE-2019-18634) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18634 https://www.sudo.ws/alerts/pwfeedback.html https://www.openwall.com/lists/oss-security/2020/01/30/6 https://www.sudo.ws/stable.html#1.8.31 ======================== Updated packages in core/updates_testing: ======================== sudo-1.8.28-1.1.mga7 sudo-devel-1.8.28-1.1.mga7 from SRPMS: sudo-1.8.28-1.1.mga7.src.rpm
Status: NEW => ASSIGNEDCC: (none) => nicolas.salgueroCVE: (none) => CVE-2019-18634Assignee: pkg-bugs => qa-bugs
It turns out that this issue is not exploitable in 1.8.26 and later: https://www.openwall.com/lists/oss-security/2020/01/31/1 We can keep the patch in the package for any future updates, but we don't need to push this one right now.
Status: ASSIGNED => RESOLVEDResolution: (none) => INVALID
And now according to this PoC we are vulnerable: https://www.openwall.com/lists/oss-security/2020/02/05/2
Resolution: INVALID => (none)Status: RESOLVED => REOPENED
@David, re comment 4. I tried the PoC and could not see a segfault. $ sudo -V Sudo version 1.8.28 Added "default pwfeedback" to /etc/sudoers and set up the /tmp/pty link. $ ll /tmp lrwxrwxrwx 1 lcl lcl 10 Feb 5 15:53 pty -> /dev/pts/7 $ ps aux | grep python lcl 25672 0.0 0.0 7204 3704 pts/4 S 15:53 0:00 socat pty,link=/tmp/pty,waitslave exec:python -c 'print(("A"*100+chr(0x15))*50)' $ sudo -S id < /tmp/pty uid=0(root) gid=0(root) groups=0(root)
CC: (none) => tarazed25
Ok, we'll see if upstream issues any further guidance.
The discussion at https://www.sudo.ws/alerts/pwfeedback.html recommends a simpler procedure to reproduce the bug but it does not work here. $ perl -e 'print(("A" x 100 . chr(0)) x 50)' | sudo -S -k id uid=0(root) gid=0(root) groups=0(root) $ sudo -l Matching Defaults entries for lcl on difda: requiretty, pwfeedback, env_reset, env_keep="COLORS DISPLAY HOSTNAME ......
https://www.openwall.com/lists/oss-security/2020/02/05/5 Looks like we're ok.
Resolution: (none) => INVALIDStatus: REOPENED => RESOLVED
Now the note added to the upstream advisory notes how someone showed it can be exploited in newer versions, even though the older note about them not being vulnerable hasn't been corrected. Given that Ubuntu has patched 1.8.27, let's go ahead and push this update. https://usn.ubuntu.com/4263-1/
Mageia7, x86_64 $ sudo -V Sudo version 1.8.28 Sudoers policy plugin version 1.8.28 Sudoers file grammar version 46 Sudoers I/O plugin version 1.8.28 $ sudo --list Matching Defaults entries for lcl on canopus: requiretty, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC 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 User lcl may run the following commands on canopus: (ALL) NOPASSWD: ALL Yes, it works fine here ( sudo useradd, sudo passwd <newuser>, sudo drakconf ) There are a lot more options. Taking them on trust.
Whiteboard: (none) => MGA7-64-OK
Validating, before the situation changes again. Advisory in Comment 2.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0081.html
Status: REOPENED => RESOLVEDResolution: (none) => FIXED