Nobody Expects Command Execution: A Tribute
Or: Why you don’t let untrusted users “sudo apt-get install”
I was going through my reading list, and I found this great article, entitled “Nobody expects command execution”.
tl;dr: Lots of commands in linux have an option to let you run arbitrary commands. If you let users run those commands with sudo or setuid root they can get a root shell. Check it out, it’s got juicy examples.
This blog post is just one example of command execution using sudo apt-get
.
But why would you let your users do that!?
Letting non-admin “semi-trusted” users install their own software is a pretty
common desire. If you don’t let them, you tend to end up with 50GB+ home
directories containing the entire Gentoo package set just so they can use
zsh
.
Really, sudo
seems the obvious way to let users install software.
There are
plenty
of
examples
of web pages either suggesting to use sudo, or that it’s merely “less secure” than
the “correct” solution (which seems to be Polkit?).
“less secure” is a bit misleading: it’s easy to get a root shell once you can
sudo apt-get
.
Here’s how
echo 'Dpkg::Pre-Invoke {"bash";};' > dpkg-opts
sudo apt-get install cowsay -c=dpkg-opts
What this does is to ask apt-get install
to supply extra flags to dpkg.
dpkg
lets you insert arbitrary scripts as hooks, so all you need to do is set
“bash” as your hook, and you get dropped into a root shell during the
installation process.
This requires that cowsay
is not installed (if it is, the hook won’t run),
but you can always pick a different package or uninstall it.
While this is pretty widely acknowledge as a risky thing to do, I couldn’t find
any actual examples of why. Hopefully this will be helpful to people
considering giving out sudo apt-get
priviliges to users!