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