The site explains how User M can exploit such situations to bypass this restriction. User M can thus effectively run anything under sudo.
This is one of those spots where "everything is a string" fails miserably. Sure, you can encode anything into a string, but that means your ACL system now needs to know how to decode all those formats. Or you do what we have now; regex and hope no one is clever enough to spot the bugs.
That's not even getting into the fact that shells can get input from all over. I.e. passing vars via stdin or variables.
Off the top of my head, you can open full root shells from basically any editor, I believe less can do it. You'll also have to ensure that none of the programs can crash to a debug REPL (i.e. if I can get a Python program to crash to a REPL, I can open bash or run my own Python as root).
One way or another it is going to be possible to exploit the permissions that are given to break out into a root shell.
As far as the idea that it "makes you think", given that I've absolutely typed it without thinking at all and rebooted prod, I'd say that's worthless as well.
Then there's all the silly tricks you need to learn in order to deal with shell redirection and handling of files that just get in the way of doing your job.
The only thing it does usefully is log all the commands executed, but you can hack up bash with honeypot logging patches to syslog every command executed and achieve the same thing.
If an adversary got a shell with typical developer sudo access, the game is effectively over.
You can still use `sudo` with limited accounts to prevent escalation. Let such an account run under `sudo` only a fixed set of scripts which take no parameters, and which it cannot even read (but the privileged user can). Additionally, run them from within a chroot where only needed binaries are mapped. This may not stop the most sophisticated attacker, but will thwart a number of less-sophisticated.
If configured properly, it's safe, but there's a number of gotchas, like indirect privilege escalation through improper $PAGER: https://gtfobins.github.io/gtfobins/apt/
Heck, IMO, we shouldn’t have a single role with all the privileges, opting instead for a capabilities-like system with specific admin roles for different domains of control. There are other *nixes where this was the case historically.
sudo lynx --dump https://gtfobins.github.io/ | grep https://gtfobins | tail +3 | grep -v # | sed 's/^.*\/\(.*\)\/$/\1/' | sudo less
I'm not hating on people for not knowing things - it just seems like either its already obvious and this won't help you or its not obvious and it still won't help you because its not really teaching you the right thing. Either way, it seems kind of silly.
I'm pretty sure he was taking about something completely unrelated to the stuff you're thinking of (capabilities(7), selinux, and apparmor): https://en.m.wikipedia.org/wiki/Capability-based_security
Here's what an implementation of capabilities looks like: https://capnproto.org/rpc.html
Only once?? Doing this should be muscle memory for working devs.
I was a sysadmin in a former life, and I didn't usually expect 'sudo' to provide a thorough technical defense against a user intent on wreaking havoc. As typically configured, with blanket access to one or more tools that allow arbitrary file manipulation, it's more like a subtle nudge than a real guardrail. You hope and assume the user respects you and their access level in a way such that they don't work around obvious intent.
It's of course possible to limit the use of 'sudo' carefully (i.e., restrict it to invoking wrapper scripts around specific functions which accept minimal user input) but it's often not expedient to do so, and often expedience rules the day.
It only really crosses a security boundary if, for some reason, dd is configured to run as root (e.g. via setuid bit, or sudo config). At that point, you could use it to patch the filesystem directly anyway, but keeping things in-memory is much stealthier (and less risk of bricking hardware, if your working with an embedded device or similar).
For a description of using dd to gain file-less native code execution, see .
As a concise (golfed) example (x86-64 /bin/sh shellcode):
cd /*/$$;read a<*l;exec 3>mem;base64 -d<<<McBIu9GdlpHQjJf/SPfbU1RfmVJXVF6wOw8F|dd bs=1 seek=$[`cut -d\ -f9<<<$a`]>&3
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  (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  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.
So if you are trying to privilege escalate a linux box and sudo -l returns:
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"
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?
Also LOLBAS (Living Off The Land Binaries and Scripts (and also Libraries)
And that's when you realize how many websites there are out there that make simple attacks so much easier.
* You can hack free boxes and get a mediocre VPN connection to their boxes (that are playable as free). It's doable, but I got annoyed by certain things.
* You can get a subscription for (I forgot) like ... 10$ per month? And then you get a good VPN connection to an entirely different set of servers. It also opens up many more boxes to hack!
* pro labs, which are more in depth than the regular boxes and likely have multiple targets
* job postings, which I assume employers pay to post
* academy, which is more guided training than the regular boxes
* T-shirts and swag: https://hackthebox.store/collections/all