Most of them by very far rely on sudo. I've got a system without sudo. The only way to execute something as root on my system is to log in, using a U2F security key, from a second system (typically a small laptop sitting next to my workstation). That second system is connected to my workstation on a dedicated LAN only used by these two machines. Firewalls on both (for example my workstation only allow SSH in from that one LAN and only from the IP of my laptop on that LAN etc.). The laptop has no Internet access, WiFi disabled (modules prevented from loading, firewall preventing network access, etc.). The laptop's sole purpose is to run command as root on the workstation: it's its sole purpose.
The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation.
I think no sudo even installed on the machine beats the "never allow root SSH" mantra but YMMV.
(to set up the system I install the system offline, from a Debian installation medium whose checksum and signature I've verified, do my thing as root on the workstation, set up the login using U2F from the laptop, then I "lock myself out" from login as root directly at the workstation by entering a password so long I'll never enter it, something like "neverenterthisrootpasswordanymoreusethelaptopu2fkeyinstead#$bey8rUtIopTY6"*. A bit of pain to enter twice but then I'm good to go)
Out of curiosity: What sensitive things does the root account protect on your workstation?
On my desktop (and probably 99% of people's desktops here) getting access to the user account is game over. The password manager? Runs as my user - one ptrace and the key can be extracted. Cookies for all my online services? Sitting right there in the home directory.
The only thing root access would give somebody on my machine is to uninstall some random packages or corrupt my install.
And don't get me wrong, I don't like this situation - I tried running some high-risk programs (browser, Libre Office) under flatpak to achieve at least some separation - but it breaks too many things.
Probably not 99%, no. It may be worth noting that macOS doesn't have these issues. The password manager doesn't run as the user, and entries in it have ACLs that restrict which apps can read them. In turn that's enforced by the kernel: apps can't ptrace each other and they can't tamper with each other's files. Browsers, meanwhile, encrypt the cookie store using a key stored in the keychain, so you can't read the user's cookies either.
All this is true without app sandboxing being activated. Apps that are sandboxed get even more protections.
Apple have done the best job of incrementally isolating apps from each other using different levels of sandboxing. Linux and Windows are far behind even with Flatpak. For example, we tell people who use Conveyor (our product for deploying desktop apps [1]) that one of the most secure platforms to do signing on is a Mac laptop, because the signing keys can be protected such that only Conveyor itself can read them. Even if you execute malware, it would trigger a permission prompt if it tried to access the signing keys, and then the process doing the signing is also protected in the same way. To get the same effect on Linux you'd need to set up dedicated UNIX users and the like.
Maybe I should write up a blog post on this stuff. Apple tighten things incrementally with each major release and don't make much noise about it, so I've found a lot of people aren't aware of how advanced their security has actually become.
security so advanced that an individual software author cannot write a small MacOSX app, add an About box and cool icon, and distribute it themselves, as they choose?
Assuming by "as they choose" you mean without buying a Developer ID then yes, they can do these things. In fact if you don't supply signing certificates Conveyor will self-sign your app and produce an HTML download page with instructions telling the user how to bypass GateKeeper. It'll also generate a `curl | bash` one liner to install it from the terminal. Obviously, this isn't meant for consumer software. Really you shouldn't bypass GateKeeper even if you're a pro level developer, although of course in reality we all do it.
I too used to be maximally skeptical about this stuff. I saw what Apple did with iOS and like so many others saw the writing on the wall. But it's been 15 years now and you can still distribute and run unsigned Mac software if you want to. Developer ID/notarization remains very different to app review. App sandboxing remains optional. You can still get root if you want, both the default de-privileged version and the full fat version (by disabling SIP).
In the end the wall writing existed only in our minds. Apple have never closed the macOS platform like with iOS, and honestly I see no sign they ever will.
I thought about using Qubes OS on my new computer but it seemed like a lot of work and tweaking and still having to live with the limitations so I abandoned the idea.
If you're really paranoid, Qubes has a "USB qubes" vm to handle untrusted USB devices. Then you only need to trust that the attacker can't tamper with PS/2.
> The only thing root access would give somebody on my machine is to uninstall some random packages or corrupt my install.
While I agree that compromise of an unprivileged account has significant costs, technically superusers do have significantly greater access to the system and so there are greater levels of risk.
RedoxOS is reimplementing Linux userspace utilities in rust in order to avoid C vulns in suid binaries; like ping, which requires raw sockets for ICMP (which most of us only need the Echo Request capability of)
On my system the root account is primarily for upgrades, but also storage administration! ZFS snapshots protects me against silly mistakes like strange permutations of `rm -rf ~/` in day to day operations. Not having root all the time protects me against `zfs destroy -r nagato/data/home/drbawb` which will nuke my home folder, 144 frequent snapshots (15 minute intervals per 36 hours), 14 daily snapshots, 4 weekly snapshots, and 3 monthly snapshots. That would suck. A lot. (I have a file called "RIP", where a drive image used to be mounted, because I got a little too over-zealous with the recursive option on some ZFS commands on a file that had `copies=1`. _RAID is not a backup, snapshots are not a backup, etc._)
This also means that theoretically ransomware (running without root) could encrypt my home directory, but apart from doubling the number of blocks used on disk it would have no real impact on my data. (If someone writes a virus that can encrypt the blocks inside a ZFS partition, without mangling ZFS data structures beyond repair, then I'll be more impressed than angry. Not even the ZFS devs can rewrite block pointers on a running filesystem.[1])
That being said ZFS has an awesome feature called delegation which lets you run a subset of commands without root permissions. I use it sparingly, mostly to allow unprivileged backups. (Each host gets a login on my backup server, and can only create/destroy datasets that are children of a host-specific dataset. So `nagato` can `zfs destroy -r backup/hosts/nagato` but not `zfs destroy -r backup/hosts` or `zfs destroy -r backup/hosts/someone-else`.)
* Logs: If my unprivileged user gets compromised, there's a much better chance that I can figure out what the attacker did if he can't wipe his traces as root.
* Money: I use a different unprivileged user for general use and for banking, so a compromise of my general purpose user doesn't immediately mean that my banking stuff gets compromised.
* Lateral escalation: Similarly I use another user to verify the checksums or PGP signatures of Windows/Linux images, so I don't end up booting a compromised image even if I download it from a compromised browser.
The ptrace issue you mention can be avoided by using the Yama LSM.
You mention that you tried Flakpak for isolation. If you set up a well-protected root account, along with multiple unprivileged users, you can also get isolation, but between different security contexts rather than different applications. It is less convenient than Flatpak for daily use, but is extremely mature and doesn't require any of the extra layers (user namespaces, bind mounts, proxies...) that Flatpak uses.
I see that reasoning very often but I don't agree with it (note that I'm not saying a local exploit is great).
But first I'll start with a question: why don't you (and everybody else for that matter), run everything as root?
Why don't we all search our entire disks for every single executable and then execute chmod 777 on all of them? I mean: that'd make for a good XKCD...
If the idea is that it's game over anyway if there's a local exploit, we may as well just run everything as root right? Why even bother with sudo at all?
> Out of curiosity: What sensitive things does the root account protect on your workstation?
I'm one of those person using several user accounts on my own system. For example my professional account is separated from my personal account (and I do use both simultaneously). One of my browsers (I run several browsers) is in a throwaway user account: clean slate at every launch. Why not?
And a local exploit compromising one user account requires a second exploit to access what's in the other users accounts.
> The only thing root access would give somebody on my machine is to uninstall some random packages or corrupt my install.
Root access could allow the attacker to install a persistent backdoor which would be very hard to detect. Installing a persistent backdoor that can evade detection is incredibly harder to do if all you have is a local exploit.
I take a system on which I have more chances to detect that an exploit happened --even if the exploit did already happen-- any day over one with less chances to detect that an exploit happened.
And even if, for me, a local exploit means it may be too late for some stuff (although having U2F/webauthn and soon passkeys in many important places should limit damages), having a non-compromised root may allow me to detect a local exploit and share my findings with the community. Which has a lot of value too.
They don't rely on sudo. The sudo tag merely indicates that if sudo is configured to allow "your" (the pwned) user account to run them, they can also be used for privileged operations that might not have been intended by whoever configured sudo that way.
"Never allow root SSH" together with the strong implication that it should be used in conjunction with sudo, has always had a very weak rationale behind it, since as soon as you actually ever make use of sudo to elevate your privileges, for an attacker there is almost no meaningful distinction between your user account and plain root.
Looking at the historic reality, the weak rationale more than evaporates completely. Due to various CVEs, sudo has, in retrospect, been a trojan horse for most of its existence that allowed privilege escalation from any user account regardless of its configuration. The period for which sudo has had these vulnerabilities overlaps rather well with the period for which it has been championed as "best practice" along with the tenuous justifications based on security by obscurity and to avoid "user mistakes."
In that light, your setup seems perfectly sane to me, however I don't believe sudo is relevant as a backdoor anymore in 2023 and the focus has most likely shifted to something else.
>The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation.
Allowing root login is fine. The best practice is not to allow passwords for root login.
I somewhat like smartcards more. Takes use of the slot, not wasting rare USB ports on notebooks. I don't why there are so few USB ports, but that's another discussion.
I think at this point you are solving a wrong problem. Getting root access through X zero days exploits is not so hard. And if you uninstall `sudo` and `su`, and only login as root on dedicated TTY, you have very similar security.
I use Qubes OS for stuff like this. Way better security, no need to juggle tokens, dedicated lans and so on. Only real problem is no graphical acceleration in browser (Google Earth...)
Doesn't Qubes require like 32GB of RAM just to run?
I would love to use it, but most of the use cases I would like to try it for are much more in the realm of SBCs with 2-8GB of RAM for running services locally.
It would be great to have that extra security, but the cost is really really high.
> Doesn't Qubes require like 32GB of RAM just to run?
32 GB minimum, but 16 GB recommended.[0] I think that's backwards, so I'd say it's actually 16, not 32 required. But yes, that's more than a typical SBC will have. The Pi 4, for example, has a maximum configuration of 8 GB, but some have modded it to have 16 GB.[1]
I was curios about that 16GB pi. (I want to have one myself :) Unfortunately, it looks like soldering the 16gb ram chip onto the pi did not increase the usable memory due to other hardware limitations. [1] https://forums.raspberrypi.com/viewtopic.php?t=350514
What really matters is not whether you have sudo (or su, pkexec, etc.) installed, but rather that you never, ever escalate privileges from a less trustworthy user to a more privileged one, since at a conceptual level this combines the low trustworthiness with the high privileged-ness.
Instead, when you want to elevate privileges, you should do so by using a mechanism that takes the control of the machine away from less trustworthy user - such as a Secure Attention Key or similar mechanism.
Yeah, they do, but (in theory) they should either only allow you to do some very restricted commands (e.g. chsh, chpasswd), or require you to authenticate to run arbitrary commands (e.g. su, sudo).
The former are fine since they don’t allow arbitrary commands/escalation, and the latter (IMO) you should not use because it’s impossible to use them safely as you can’t trust the environment (the display server, terminal emulator, shell, etc.) to do what you say if it is compromised.
In practice, some of them will have bugs (and the kernel also has privilege escalation bugs frequently) so I don’t consider the user/root separation a particularly strong security boundary. For me it’s more of an additional layer against not very sophisticated attacks.
Yeah - the whole "sudo" category just seems superfluous since the issue is with sudo, not with the individual tools.
OTOH, if people are expecting literally every program to open file handles / network sockets, then drop privileges to something else, that's a weird expectation.
Do you also disallow su on your system or is it just sudo that's been banished?
Edit: I'm curious because if you still allow su on the system there seems to be little to no reason to set PermitRootLogin in sshd_config regardless of auth mechanism (password, cert, token, etc.).
Because su was there in Unix before sudo, IIRC. And sudo means "su do", meaning do (something) as su, which in turn meant "super user" or "substitute user" according to Wikipedia, since it can also be used to login as other users than root , e.g.:
These bypasses are typically not for when are the only user and also the administrator. Sudo here is not really for securing your machine: as others have said, if an attacker gets to your personal account, it is game other. It is mostly a tool for you to avoid fucking up your system by mistake.
These bypasses are useful if you want to get root access on a machine you are given some, but not all administrative rights, like a shell and a few sudo commands, for example to restart a service.
Yes, I hate sudo's unwieldiness too. The very first thing I do after installing one of those distros that default to no-root-login (Ubuntu, Mint, etc) is to give root a password.
The downside is that I allow "root SSH", contrarily to every single best practice out there.
Why can't you log in via SSH as a 'normal' user, and then "su -" to become root? I use that method, and it obviates both the use of sudo and the allowance of "root SSH".
So if I understand correctly, one of the most common flags is "sudo" and it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running.
I suppose that's a fundamental design flaw in POSIX setuid operations. Setting real/effective UID/GID in a process is persistent, and tools don't normally keep checking to see whether they have/need elevated privileges, and so this happens.
Now I expected this tag to mean something else. I expected there to be a list of tools that are commonly granted to ordinary users in the sudoers configuration, like the operator being able to kick off a backup. For example, "less" has a shell escape, and when running under sudo, it was possible to simply shell out and have an unrestricted root shell. I think that's fixed, but the moral of the story is not to grant sudo access to any tool that has shell escapes or arbitrary command execution.
In my experience, if you see * or more rarely ? in a sudo command configuration then there's a good chance there's a problem.
I once saw a bunch of systemctl start someprefix* being allowed in a sudoers configuration (likewise for stop). systemctl can start more than one service at a time and the way that the sudoers configuration is checked is by glob matching the concatenated command.
If your command is literally: "systemctl" "start" "someprefix" "sshd" this gets concatenated to "systemctl start someprefix sshd" which matches the glob "systemctl start someprefix*".
> it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running.
No, it doesn't seem to mean even that. It just means that … the thing might do something construed as privileged, if the user running it is privileged.
Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? This is solidly on the wrong side of the airtight hatch: I'm not "bypassing security restrictions", I've been granted access to read a file otherwise restricted with sudo. If you grant someone access to running `cat` as root, I can't imagine how it would be a shock that they can then read files that only root can read?
> if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea.
It might be a bad idea, but that's not "bypassing local security restrictions", that's explicitly changing the local security restrictions such that that's not a restricted command for the user you're granting it to.
If you don't want someone to be able to read any file on the system, no, you shouldn't grant them the ability to run "cat" as root! But "I granted them X" "they ran X" → "they bypassed local security restrictions" is non sequitur.
I am not entirely sure what to make of this list. Naturally if a binary or script are given sudo rights then that will elevate privileges, and by default anything should be considered as potentially vulnerable, malicious or misuse-able, particularity tools that can write or read files or execute other binaries or scripts, making this list ... obvious?
No. If you have a program that does a particular task you may be inclined to let users run it with sudo rights. This list shows how these rights can be used to - for example - read arbitrary files and show them to the unprivileged user.
The lesson here is just don't rely on sudo to give restricted permissions. I have been a Linux admin for 6 years and never had to do this, and pretty much every use case I've heard of has easily solved with a better method. If you need to give people access to certain files, make a group. If you need them to have certain capabilities of another user, let them switch to that user but not run privileged commands.
> > But that is one of the headline features of sudo! For example it is the first item on its feature list here https://www.sudo.ws/about/intro/
> The ability to restrict the commands a user may run on a per-host basis.
Is it? sudo is literally "substitute user [and] do" and it does exactly that: runs a certain program in the context of certain user. The only permissions sudo is concerned with is which user on what host is to be allowed to switch to which user, i.e. invocation permissions. Sudo simply does not care what permissions user+program combo may have.
Without additional hardening, in unix-like systems local user account is the capability boundary and `sudo` is a tool to escape those boundaries. Sudo is just doing what it was designed to do here
> The only permissions sudo is concerned with is which user on what host is to be allowed to switch to which user
And, critically, what commands that user is allowed to execute. That is pretty crucial aspect of sudos use-case. The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution.
> The intent is to have ability to restrict what code the user is allowed to run as the target user, and not allow arbitrary code execution.
No, that's not the intent. The intent is at best to limit binaries that are being run, but actual implementation is to limit invocation string.
> That is pretty crucial aspect of sudos use-case.
Agreed. Unless you 100% vet and control all sudo`able binaries in your system (probably 99.9% sysadmins don't), it is pretty crucial to understand that effectively sudo grants arbitrary code execution under x user permissions.
That's by design. Executed code runs "natively", not in any form of sandbox, without any restrictions on permissions besides local user account. Some applications are explicitly designed to allow arbitrary code execution, some applications may have bugs allowing arbitrary code execution.
Sudo is insecure by design. The main use of sudo is to protect against willingly cooperating users.
And sudo does its job, executing only that program as root. If the sysadmin turns out to not want users to be able to use all features of the program as root, that is their responsibility. Sudo is just a command executor, not a sandbox
It's essentially the same as setuid, which has a well-deserved reputation for being a very dangerous tool if used on a program without thorough scrutiny
I still don't get the issue, that's going to be true for any program you run, unless it explicitly check if it's running using sudo. That however assumes that the program should never run with elevated privileges, which may be equally wrong.
Unless a program is designed for a very specific task and should always run as a given user, I'd argue that having it check privileges is both surprising and wrong. It's not the job of the individual programs to check permissions.
Edit: I see what you're saying. Having mail being a program that a user is allowed to run with sudo, it basically the equivalent for giving them a sudo access to a shell, because mail can spawn a shell, but with the same privileges as the mail command had.
One of the listed binaries is `cat` and that `sudo cat file` is problematic because "it may be used to do privileged reads or disclose files outside a restricted file system."
Like, duh, that is what `cat` does. It's not the problem, it's the `sudo` is the problem. WAI?
I think the listing of "non-obvious" functionality is interesting. For instance, would you have expected to be able to use gimp to get a reverse shell? Would you have thought of using lp as an exfil tool? Or just bashing your exfil into base64-encoded whois requests?
Living off the land is always a fascinating topic, at any level.
If it can perform arbitrary file writes (or even reads) then sure, I'm not at all surprised. A program with root access to the filesystem should be assumed to be a latent portal to arbitrary root execution, unless very thoroughly proven otherwise
There's a reason setuid is considered such a dangerous bit, and why "get root via this secure-looking setuid program" is a common exercise in computer security courses. Gotta look out for path traversals, TOCTOU, untrusted environment variables etc.
Part of the logical problem is the clash of security models. The program may well have been written to guard against untrusted input, but considers that to only be input files, not the commands the user gives. On the basis that "well if the user wants to hurt themselves by writing to /etc/shadow then it's their choice". But the situation in practice is a confused deputy problem, where the sysadmin wants the user to be restricted (despite the process not being restricted) but the program doesn't "know"
In a previous role we had some access to production web servers but definitely not root access. Except for sudo access to vim which was widely abused as a way of getting a root shell when necessary. Fun times.
It was originally compiled for penetration testers/offensive security people. You land on a box with low priveleges, check around for commonly misconfigured binaries, and get root.
For the sake of this argument, lets suppose you run a git server. Users $(ssh) into your host and are only allowed to execute the command $(git), for instance for submitting a copy of their repository. You think: It's fine, the user cannot mess up anything on this system since he is restricted to run git.
Allowing any user $(git) access is as powerful as providing the user a $(bash)
Suppose you've got a build pipeline. The pipeline executes $(zip) at some point. Executing zip is as powerful as providing any of the pipelines users a $(bash).
And that is the whole idea of having a list like this. These tools by default have some capabilities which can easily be executable. You need to mitigate each of those. Because they are insecure by default.
> 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.
LFILE=file_to_write
echo DATA | sudo tee -a "$LFILE"
Yes... this is how it works?
What does the author expect? Sudo executing programs with root privileges resulting in not using them or what?
I'm certain the author has bogus expectations here.
> It is important to note that this is not a list of exploits, and the programs listed here are not vulnerable per se, rather, GTFOBins is a compendium about how to live off the land when you only have certain binaries available.
You can directly map most of the tags into a libc function clall combination, like the "Command" tag is just programs that run user input into a system() call. Even for programs where this is their primary function. It has nothing to do with "bypassing".
The author is making a security theater out of nothing for posing.
The point is to get to these functionality from a limited set of shell commands, not to get to this functionality from an arbitrary executable.
> The author is making a security theater out of nothing for posing.
Again, the author is not making accusations of security flaws. I don't know how they could have described it better, but the author was going for something very narrow and specific.
There are quite a few comments here questioning why a list like this might exist, the focus should be on this in the intro:
> bypass local security restrictions in misconfigured systems.
Someone may think that they can give users restricted access, but this is likely not the case as it is easy to misconfigure the system to give full access. That's the takeaway for me: any access is probably all access.
A very clean example is `aws help`: an admin may think that allowing a user to run the help command just grants them access to help, but the example shows that the user could then run any command:
Still, most of these commands will also have bugs. Even if they didn't have convenient built-in ways to escape a restricted shell, I would not expect that these command-line programs, which weren't built to be run in an adversarial environment, weren't vulnerable to buffer overflows or logic errors.
The lesson appears to be that if you want to put users in a restricted environment, don't rely on unaudited unix command-line programs to enforce it. Instead do something at a level below that, such as using a kernel-enforced mechanism.
The "suid" and "sudo" terms are not the conventional meanings, which to my mind sensationalizes this list, which is otherwise useful.
Real "sudo" has "noexec" which (mostly) prevents issues by way of .so injection to override libc exec() functions (see the "awk" sudo issue for example). setuid/setgid are not to be used lightly, the problem isn't with the program if an admin overrides the permissions it gets.
This used to be one of the first things I'd run hardening a linux system:
find / -type f -a \( \( -user root -a -perm +4000 \) -o \( -group root -a -perm +6000 \) \)
> Real "sudo" has "noexec" which (mostly) prevents issues by way of .so injection to override libc exec() functions
LD_PRELOAD hacks are ugly though.. seccomp filter would be nicer, but apparently you can't really block execve with seccomp. Best thing I found was to ptrace the child, and inject seccomp policies after startup. That is not exactly pretty either, but what other options are there that would also work with static executables?
This whole lkml thread is bit depressing, not because the responses are wrong or bad, but because of the hodge-podge nature of unix prevents any easy solutions to fairly reasonable feature request https://lore.kernel.org/all/202010281500.855B950FE@keescook/...
this listing is kinda misleading as most cases of sudo/SUID are
not "it calls sudo" / "has SUID set"
but "if called with sudo/suid it will not drop the elevated privileges" (or refuses to run).
this doesn't mean the table hasn't it's uses but most of the things in it don't allow you to bypass security restrictions by themselves at all even if supper buggy implemented, you always need to already be able to do some privileged operations, like setting suid root, to be able to bypass anything
I think the point is that an admin shouldn't configure these executables to be run at a different privilege level, as they are not written with that kind of security consideration in mind at all.
I think it's more like "what you can use in your toolbox for effectively exploiting some privilege escalation vulnerability".
SUID is very explicit a tool only to be used for a very few niche use cases with very carefully crafted binaries. Basically a learned sysadmin putting SUID on an arbitrary binary (like most in that list) is enough reason to fire them for gross negligence without any prior warnings even in countries with strong employee protection, it's _that_ big of a "wtf. did you non accidentally do". So you don't really need a list for that.
Similar as any small tooling binary (e.g. cat, base64, etc.) is _supposed_ to run under sudo, i.e. it's definitively not a case of "not written with that kind of security considerations in mind".
Also for sysadmins this list isn't that useful as there are any number of arbitrary additionally binaries which behave similar on most systems, i.e. the list is very incomplete (and there is no way around that).
Similar "being able to read/write a file with the permission the calling user has" is normally not something you care about, the caller is anyway allowed to do so.
Or being able to trick a program to work as a form of shell (limited to the users permission) also normally doesn't matter. The user just can spawn it explicitly.
Except if you build a toolbox you want to use after finding some (potentially limited) exploit (or if you want to consider what such an toolbox would likely use). Then is list is grate as it makes it easy to find a way to archive something (e.g. shell) with as little custom code (and potentially without it being obviously in monitoring tools).
$ sudo -l
Matching Defaults entries for yrro on wintermute:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty, env_keep+=COLORFGBG, use_pty, !fqdn
User yrro may run the following commands on wintermute:
(ALL : ALL) NOPASSWD: /usr/bin/etckeeper unclean, /usr/bin/ss
(ALL : ALL) !/usr/bin/sudo, !/usr/bin/su, !/bin/su
$ sudo -a -F /etc/shadow
Error: an inet prefix is expected rather than "root:$6$9mkIdP/HzXdF0bn6$.aUdPCsZFfm0NJ9Wse.8EowMDION0tvzApDy7X09HQwNIJX9ckvCxoDuYCxzY1uCEvUdODRCVCSoWNVMSgC9a.:16545:0:99999:7::
the "*shell","command","read/write/upload/download" lists are plausible. it's slightly non-obvious that running gdb also allows you to drop into a shell. you could envision a restricted account at a university lab or maybe a web-based system like godbolt give access to gdb, but forget about the "!". but it'd be a careless mistake. anyone who'd miss that really shouldn't be messing around with privilege separation in the first place.
the rest of it is hogwash: news flash - if you give access to bash, you've given shell access. any tool that allows you to provide a filename to be read/written to can be used to read or write over arbitrary files. so let's make a list of programs that can read/write files.
just about every entry under the other categories "sudo","su","setuid", "capabilities",etc. simply involves chaining sudo, su, suid etc. with a shell breakout which is already listed under "shell". the issue is still the shell breakout (or read/write/etc.)
the problem is that this list is inverted. here's my curated list of programs that are safe to run under sudo/su/setuid/etc. without being explicitly designed to do so, in all conditions, without knowing what you are doing: {}.
there are over 50,000 packages in Debian. why not just list them all here?
this reads like junior admin with introductory knowledge of cyber and UNIX trying to make a typical, useless, prescriptive list/recipe for something that instead requires specific engineering to accomplish something given the actual use-case and specific threat model.
I think you're confused about the purpose of this project. From the website:
> It is important to note that this is not a list of exploits, and the programs listed here are not vulnerable per se, rather, GTFOBins is a compendium about how to live off the land when you only have certain binaries available.
This website is essentially a lookup table that teaches you how to break out of programs that you find on a system, but aren't intimately familiar with, e.g. during CTF challenges.
ah, makes sense, that also explains the slightly amateur-hour nature of some of them like shelling out of vi or gdb. I read the thing about not being vulnerabilities per-se (and if it hadn't have said that I'd have been irritated), but I did not catch the context of "live of the land".
> su
Sudo
Sudo
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.
sudo su
So it is su or sudo ?
Anyway, this is in the spirit of "to install a linux virus: ./configure; make; sudo make install".
There is a lot of misunderstanding of context in the comments here. This is a list intended for penetration testers in the privilege escalation phase of exploiting a system, after they've obtained access (the ability to execute with arbitrary parameters) to some "restricted" binary on the possibly misconfigured system.
It's commonly used in CTF competitions. For practical examples of when it's been useful, search for something like "gtfobins tryhackme writeup."
As a defender, the lesson should really be that you shouldn't assume a binary only does one task. As always, you need to be extremely careful passing untrusted user input to a binary, especially if invoking it via a shell.
The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation.
I think no sudo even installed on the machine beats the "never allow root SSH" mantra but YMMV.
(to set up the system I install the system offline, from a Debian installation medium whose checksum and signature I've verified, do my thing as root on the workstation, set up the login using U2F from the laptop, then I "lock myself out" from login as root directly at the workstation by entering a password so long I'll never enter it, something like "neverenterthisrootpasswordanymoreusethelaptopu2fkeyinstead#$bey8rUtIopTY6"*. A bit of pain to enter twice but then I'm good to go)