A normal user can execute these commands as root without providing any password (sudo includes the full path of the command so path hijack isn't the case here), could "halt", "reboot", or "poweroff" be leveraged to escalate the users' privileges to root?
2 Answers
The ability to invoke as root is not a property of the names halt, reboot, or poweroff, but of the files that are executed. The setuid bit is a file permission bit that means whenever you try to execute the given file, it is run with the permissions of whoever owns it (in the case of su, sudo, halt, reboot, and poweroff, root). You cannot use mucking about with $PATH to, say, make halt point to your own executable that gets invoked as root—if you hope to abuse setuid for privilege escalation, you must find a bug in an already-extant setuid program on the system (which is precisely why setuid program bugs are considered utterly critical).
EDIT: Seeing a comment on the question has made me reevaluate what the question means, and realise the following may be better suited as an answer:
If you've configured /etc/sudoers to allow normal users invocation of an absolute path only (as you have in fact done), then whether or not users can muck with the $PATH that sudo calls on (according to the manpage, changes to $PATH pass through sudo to the executed command unless the security policy resets it, although the default security policy does), they cannot invoke arbitrary binaries named halt, reboot, or poweroff, since you specified a unique path. Once again, only if those binaries themselves can be exploited, can someone cause trouble—but the attack surface is much bigger if you're allowing the execution of a binary that wasn't originally made to be setuid. You should make sure your /etc/sudoers security policy resets environment variables, to limit the range of attack (and prevent, e.g., abuse of a sudo'd shell script which uses the $PATH)—by default it does if you haven't tampered with the env_reset flag. You can double-check by setting some environment variables, including $PATH, and doing sudo env to print all the environment variables a program run by sudo gets.
-
There's a an important point to make about they cannot invoke arbitrary binaries named halt, reboot, or poweroff, since you specified a unique path - while true for these on my system, many binaries provide an easy way to escape to shell (e.g. vim, mysql, man), which might not be obvious to person configuring
sudoers.– domenCommented Mar 22, 2021 at 9:27
The answer can be simple. Just like how you're doing privilege escalation by using cronjobs. You find a writable file and put your payload in then wait.
sudo -l gives "/usr/sbin/halt", "/usr/sbin/reboot", "/usr/sbin/poweroff" that means one thing here. You can reboot the machine as ROOT.
So, you need to look for some writable configuration files that trigger when start/reboot. find . -writable on /etc or just run linpeas.
The file is most likely owned by root. But read and writable in our favour. e.g.
ls -lh /etc/systemd/system/some.service
-rw-rw-r-- 1 root rob /etc/systemd/system/some.service
Maybe the file is running by root, then you find the exec line add ExecXXX: you evil payload here.
Or change the runner of it if that's not triggered by root in default. User: low_level_user -> root
sudo- does this mean the files are insudoers? Or are theysetuidlike the answer suggests?sudoand just assumed it was setuid :p answer updated