There is a feature of sudo to allow only certain user/command combinations. E.g. User M can only run "apt" under sudo.

The site explains how User M can exploit such situations to bypass this restriction. User M can thus effectively run anything under sudo.

But with sudo you can specify which parameters are allowed for that binary (or the whole command line). But TBH IDK if this applies to I/O redirections as well.

Every time I look at this, my conclusion is that sudo is a great tool for limiting coworker access and a terrible tool for limiting adversarial access.

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).

I've always thought that sudo was almost totally useless.

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.

There is a sort of narrow applicability of it so that you can grant some unprivileged operator the ability to run a script -- hopefully well audited with very limited number of knobs that it exposes -- to run with elevated privs. But the common use of it to give out access to nearly everything other than shell to system admin roles is pretty pointless and annoying.

Interactive `sudo` is good for awareness: "look, you are running this command with elevated privileges, unlike normal".

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.

Yes. That's why this isn't a "these are exploits" list, but a "this is where you need to be careful" list.

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/

Exactly! GTFOBins is an educational tool, not an exploit list, in my opinion.

Hopefully, the "education" going on here is that whitelisting 'sudo' command lists is leaky as all hell, and that it is not to be relied on at all to keep a system safe from attack.

You are viewing the list from a position of great privilege, due to your greater knowledge. Many devs don’t understand how sudo or setuid binaries even work, some may not even know that sudo itself is a setuid binary. Asking interview questions like “how does sudo work” yields interesting results ranging from “magic/witchcraft” to “it’s part of the Linux kernel”, even in some very senior engineers. As an educational/training tool, including at least one example of the unintended consequences of ill-formed sudo configurations and setuid binaries in GTFOBins makes sense to me.

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.

You are viewing the list from a position of great privilege

  sudo lynx --dump https://gtfobins.github.io/ | grep https://gtfobins | tail +3 | grep -v # | sed 's/^.*\/\(.*\)\/$/\1/' | sudo less

That first sudo was probably not necessary. Thanks for the laugh. :)

You don't need to understand how sudo works to know what it does. If you didn't know that running `sudo cat someFile` will leak the contents of the file, then this list is at the wrong level, and probably won't help you.

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.

Linux has capabilities(7), as I'm sure you know, but security is complicated, and the practical thing to do is still to turn off selinux and apparmor if you're running into weird problems. There are absolutely use cases for them, but "complicated" is a bug, not a feature.

capabilities(7) is pretty useless in practice because most of those capabilities can be escalated into full root access. The man page does a terrible job of explaining the security implications.

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

True, yet in a few cases the not-dropping of privileges is a real risk, like with `less` [0], which allows for arbitrary shell access despite being meant for for just paging. Also, it's useful to know that a program is sloppy with permissions in case any bugs are found in it; a CS prof I once had always insisted we dropped permissions and capabilities as soon as we were done with them so that any calls to other libraries or our own buggy code could do the least damage possible, just like how it's good practice to not run every command as root.

[0]: https://gtfobins.github.io/gtfobins/less/

> a CS prof I once had always insisted we dropped permissions and capabilities as soon as we were done with them

Only once?? Doing this should be muscle memory for working devs.

Indeed, if you trust somebody enough with a login on your system, you presumably have an expectation of some kind of good faith. If you further grant them sudo to run binaries like these with arbitrary args, that implies some even greater level of trust, and that user presumably understands the social contract at play. They should know to abide by the intent of the sudo restriction (rather than trying to work around it with clever invocations).

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.

You still need to make sure that these programs are set up such that they don't accidentally allow more access than you expected them to.

This list is completely useless to someone that doesn't know base64 reads files.

Before reading this list I didn't know that base64 can read files. So it's useful in the respect that a novice can get a better understanding of their attack surface (I think, I'm a novice to this after all) :)