gtfobins turns an allowed sudo rule into full root

the sudo rule that backfires

somebody, somewhere, needed a way to let a low-privilege user run backups. so they added a line to sudoers letting that user run tar as root. seems reasonable. tar is just an archiving tool, right. except tar, like a bunch of other totally normal unix programs, has features that were never designed with "sudo" in mind, and those features can be twisted into a root shell in about two seconds.

this is the whole idea behind gtfobins, a public list of ordinary binaries (tar, find, vim, less, python, and dozens more) that can be abused for privilege escalation, file reads, or shell breakout if you can run them with elevated rights or unusual flags. it's not a secret hacker toolkit. it's a list of features. that's what makes it dangerous, and also what makes it fixable.

step one: check what you're allowed to run

sudo -l

this command shows you exactly what the current user is permitted to run as root without a password, or with one. if you're auditing your own box (or your own team's servers, which you should be doing regularly), this is where you start. anything on this list that appears on gtfobins is a live exposure, not a theoretical one.

breaking down the tar example

sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh

let's take this apart piece by piece so it's not just magic incantation:

-cf /dev/null /dev/null tells tar to create an archive and write it to /dev/null, essentially a throwaway operation. tar needs to actually be "doing" something for the rest of this to trigger.

--checkpoint=1 is a legitimate tar feature meant for huge archive jobs. it tells tar to report progress after every 1 file processed, useful if you're archiving a terabyte and want status updates.

--checkpoint-action=exec=/bin/sh is the part that matters. this flag lets you tell tar "when you hit a checkpoint, execute this command." that's a real, documented feature for things like triggering a notification script mid-backup. but nothing stops you from pointing it at a shell instead.

put together, tar hits its checkpoint almost instantly, executes /bin/sh, and because the whole tar process is running under sudo, that shell inherits root. no exploit, no cve, no memory corruption. just a feature used exactly as documented, pointed somewhere it shouldn't be able to reach.

why this isn't a "tar problem"

the pattern repeats across dozens of binaries. find has an -exec flag. less and vim can drop to a shell command from inside the pager or editor. python can spawn a subprocess. none of these are bugs. they're features that make the tools genuinely more useful for their intended job. the vulnerability isn't in the binary, it's in the sudo rule that assumes the binary will only ever be used for its "obvious" purpose.

this is why "least privilege" gets repeated so much it sounds like a cliché. it's not about being paranoid, it's about recognizing that almost every general-purpose tool has an escape hatch, and sudo access to that tool is sudo access to whatever the escape hatch leads to.

how to actually check and fix this on your own systems

run sudo -l on every server and workstation you're responsible for. cross-reference anything listed against gtfobins.github.io. if you find a binary you don't need root access to run through sudo, remove the rule entirely.

if you genuinely need sudo access to a tool like tar for backups, scope it down hard. use a wrapper script that only allows specific flags, and lock the sudoers entry to that exact script path instead of the raw binary. something like:

user ALL=(root) NOPASSWD: /usr/local/bin/backup-wrapper.sh

where backup-wrapper.sh only calls tar with a fixed, hardcoded set of arguments, no user-controlled flags allowed through. that closes the door on checkpoint-action and anything like it.

also check for wildcard sudoers entries like user ALL=(ALL) /usr/bin/tar *, that trailing asterisk is an invitation. pin exact arguments where you can, or better, avoid sudo entirely and use file permissions, groups, or a dedicated backup user with restricted access to only the directories it needs.

the takeaway

gtfobins isn't a hacking trick, it's a mirror held up to your sudoers file. the fix costs nothing and takes ten minutes: run sudo -l on your systems today, check the results against the list, and rip out any rule that grants more power than the job actually requires. least privilege isn't a suggestion, it's the difference between a backup job and a root shell.