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.
> 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:
https://gtfobins.github.io/gtfobins/aws/