Wat. If you add someone to wheel, they may abuse those privileges. Is this really something that needs pointing out? There are many other useful tidbits that you may not necessarily know but this one struck me as a bit odd.
But if such a setup is indirectly exploitable because the default $PAGER allows arbitrary code execution, that's definitely a gotcha you need to be aware of.
If a program running as an unprivileged user wants to trigger something like a software update, I'd just write a daemon that reads the trigger command over a unix socket or a signed message over a TCP socket and then runs the update. I guess you'd lose the automatic audit logging of sudo, but pretty much any programmer can verify correctness.
Or you're in a big enterprise or university that has a ton of shared machines. sudo wasn't really designed with single-user machines in mind, `su -l` is good enough for those.
For a real-ish world example of this effect, one of the OverTheWire wargame challenges [1] (spoilers for bandit) has a user login "shell" be a message saying login was prohibited, printed with `less`. When you resize your console window to a point where scrolling is needed and then attempt login, you can then interact with `less` and use '!' to run commands as the current user and print the key. Now you may say this isn't relevant to the `sudo` category of risk since who runs `sudo less` without also being able to run `sudo anything`, but many other apps use less as their pager, and some of those make much more sense to allow for general use with sudo (like say allowing all users to update apps, or any of hundreds of other insignificant things).
In short, I think the `sudo` and `setuid` notices might be better considered as "permission transparent", i.e. any permissions or access you hand to the listed tools are handed directly to the user as well. There are secure ways to not do this when writing programs, like by setting all of the real, effective, and saved uids [2] to something non-root (or the original calling user, if available) and totally wiping the capabilities sets before `exec()`ing anything, yet that's just what I remember from a computer security class a few years ago, you would probably be best off looking into it further if you're writing anything security sensitive.
[0]: https://gtfobins.github.io/gtfobins/less/
So if you are trying to privilege escalate a linux box and sudo -l returns:
(root) /usr/sbin/tcpdump
You check gtfobins for tcpdump and see that you can get a root shell with sudo access.
Can't they just run "tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z /lib64/ld-linux-x86-64.so.2" and then swap the tcpdump savefile with the file they want to execute? That will run "ld-linux-x86-64.so.2 ./savefile" after a few seconds which is the same thing as running "chmod +x savefile; ./savefile"
https://unix.stackexchange.com/questions/400621/what-is-lib6...
Anyway this whole discussion of "What if the admin was silly enough to think the execute bit did something?" is academic. If the attacker can run any binary that's already on the system as root, you've already lost.
>So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump
Complicated, when not given the rights to do so.
This is all happening in the home directory. evil_binary can written using "echo -n -e"
You can take as much time as you want to do the swap. tcpdump will only run the log-rotate program you specified after the time limit you specified has passed.
I find it baffling that you think this is a complicated exploit. It's literally the first thing I thought of, and I'm just a random programmer. A real attacker would have a lot more tricks up their sleeve and all the time in the world to google solutions to problems like this. Does your threat model assume that the attacker doesn't know how to use a terminal?
Sure when there is a will, there is a way, however it seems many here lack the experience to work on properly locked down UNIX servers, where a user is really a plain user that dances to IT music tune.
Dude we just had a whole conversation about why this does fuck-all if you allow users to run commands like tcpdump as root. Your "properly locked down UNIX servers" are just placebo.
I gotta wonder if I'm responding to an elaborate reenactment of the 90s. In what universe are "plain users" running commands on a unix server, let alone a server run by a BOFH that blocks +x, but is totally fine with root escalation?