Bugzilla – Bug 1037
Sudo version 1.8.19p1 Privilege Escalation due to PATH manipulation
Last modified: 2022-08-18 12:58:53 MDT
Description: A 0day has been discovered in sudo 1.8.19p1 allows the user to escalate his privileges in the machine by manipulating the PATH variable, this makes him able to execute, read and write with root permissions. PoC Video: https://drive.google.com/file/d/1v1LRgGUBCGrBSOikTxP6n2zRG-vhif-H/view?usp=sharing PoC Raw: ```` # Getting Sudo Version cyber-guy@instance:~$ sudo -V Sudo version 1.8.19p1 Sudoers policy plugin version 1.8.19p1 Sudoers file grammar version 45 Sudoers I/O plugin version 1.8.19p1 # Getting Current Permssion cyber-guy@instance:~$ id uid=1006(cyber-guy) gid=1009(cyber-guy) groups=1009(cyber-guy),4(adm),30(dip),44(video),46(plugdev),1000(google-sudoers) # Getting Current Linux version cyber-guy@instance:~$ uname -a Linux instance-1 4.9.0-14-amd64 #1 SMP Debian 4.9.246-2 (2020-12-17) x86_64 GNU/Linux # Generating Malicious sudoedit file cyber-guy@instance:~$ echo "/bin/bash" > sudoedit cyber-guy@instance:~$ /bin/chmod +x sudoedit # Convert the PATH env var to the current path cyber-guy@instance:~$ export PATH=. # Reading/Writing into root files cyber-guy@instance:~$ /usr/bin/sudo sudoedit /etc/shadow # You should have access to read and write and you can crack the root password too surely! cyber-guy@instance:~$ /usr/bin/sudo sudoedit /etc/passwd # You should have access to read and write, here you can add new user with root priv and take the full privesc ```` Additional Info: I've sent this vulnerability to CVE Mitre NVD to release a CVE Number to it then the users can be safe when noticing about it.
You neglected to include the output of "sudo -l". I suspect your user has "sudo ALL" privileges which allows you to run anything. Running "sudoedit" under sudo defeats the entire purpose of sudoedit since you would be running the editor as root, not the invoking user. The correct way to run "sudoedit" is either "sudoedit file1 ..." or "sudo -e file1 ...". I think you'll find that if you just run "sudoedit" by itself the PATH modification has no effect whatsoever.
Hi Todd, If you take a deep look at it you will find that the same misconfiguration appeared in 2010 under the CVE-2010-1163 [https://lab.mediaservice.net/advisory/2010-02-sudo.txt], it happened because the lack of PATH validation before execution, and it can be exploited with the same steps too.
I'm unable to reproduce this unless the user's sudoers rules allow them to run any command, such as via "sudo ALL". If the user is only allowed to run "sudoedit" (with no path), sudo properly rejects the command. [testuser@rh6 ~]$ sudo -V Sudo version 1.8.19p1 Sudoers policy plugin version 1.8.19p1 Sudoers file grammar version 45 Sudoers I/O plugin version 1.8.19p1 [testuser@rh6 ~]$ sudo -l Matching Defaults entries for testuser on rh6: env_keep+="LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET", env_keep+="QTDIR KDEDIR", !ignore_dot User testuser may run the following commands on rh6: (root) sudoedit /etc/motd [testuser@rh6 ~]$ printf '#!/bin/sh\n/usr/bin/id\n' > sudoedit [testuser@rh6 ~]$ chmod 755 sudoedit [testuser@rh6 ~]$ ./sudoedit /etc/motd uid=501(testuser) gid=501(testuser) groups=501(testuser) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 testuser@rh6 ~]$ PATH=. /usr/bin/sudo sudoedit /etc/motd Sorry, user testuser is not allowed to execute './sudoedit /etc/motd' as root on rh6.sudo.ws. If the user is allowed to run any command: [testuser@rh6 ~]$ sudo -l Matching Defaults entries for testuser on rh6: env_keep+="LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET", env_keep+="QTDIR KDEDIR", !ignore_dot User testuser may run the following commands on rh6: (root) ALL [testuser@rh6 ~]$ PATH=. /usr/bin/sudo sudoedit /etc/motd uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 But this is not a security issue since ./sudoedit will match ALL. It is not a path confusion problem. If you still believe this is a problem, please demonstrate that privilege escalation is possible when the user does not have "sudo ALL" permissions.
I’m going to do further investigations and I’ll get back to you as soon as anything comes up. Thanks for the create communication
Closing as invalid, feel free to re-open if you find a way to exploit this with only sudoedit permissions in the sudoers file.