>If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.
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.
You're kind of missing the point of sudo if that's all you use it for. sudo can also be used to whitelist specific user+program+argument combinations, so e.g. unprivileged users can run system updates, but not install new programs. These users can use sudo, but should not be able to reach full root privileges from it.
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.
I remember reading about this use case ~10 years ago. I always found it super weird and I've never had a chance to use it. Even back then, people didn't share computers unless they fully trusted each other.
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.
> Even back then, people didn't share computers unless they fully trusted each other.
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.
I also found this a bit overly obvious at first, yet when considering it from an unintended side effects/uses perspective it's actually a valid thing to consider. For example, `less`[0] might be used with `sudo` to view a file owned by another user. This is all good until you remember that you can run arbitrary commands by just hitting '!' in the paging view, which are also runs with `sudo` privileges. Though that might seem like a bit of a contrived example, through unintended features otherwise safe tools can be unexpectedly dangerous (the entire point of this site).
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.
I used to work for a company where launching a shell from within vim was the way we got privileged access on some of the customers boxes (which ran code we developed). Pretty crazy looking back on it..
Why would the attacker need to set the execute bit on the file they want to execute?
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"
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.
No, the stock tcpdump works just fine for this attack. You were replying to a guy talking about this scenario where the attacker can run tcpdump as root:
>So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump
Swapping the file is as easy as running "mv ./evil_binary ./savefile".
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?
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.