Just a couple days ago Debian has released qemu security update (DSA
5983-1), addressing qemu-user + binfmt vulnerability which were present
in debian (and ubuntu) for over 15 years. The prob is that qemu-user
binfmts has been registered with C flag, which means qemu is run with
elevated privileges (as root) when asked to provide interpreter to a
suid foreign binary. Apparently no one realized how bad it is, until
now. qemu was never supposed to be used like this, yet a few linux
distributions wrongly enabled this C flag.
To demonstrate how bad it is.
# debootstrap --arch=armel --variant=minbase bookworm /chroot/bookworm
this will populate /chroot/bookworm with an armel debian bookworm
installation. Almost any linux install includes a few suid-root
binaries, for example the traditional *nix /bin/su. Now, for any
user on the system, starting with an easy one:
$ QEMU_LOG_FILENAME=/etc/shadoww QEMU_LD_PREFIX=/chroot/bookworm \
/chroot/bookworm/bin/su
(just hit Ctrl+C to the su prompt).
$ ls -l /etc/shadoww
-rw-r--r-- 1 root mjt 0 Aug 14 21:56 /etc/shadoww
this makes qemu write any file as root. Not with a given contents,
but the fact it writes to whatever file it is told to write is already
interesting.
Now, something more interesting would be to provide a modified
lib/ld.so or lib/libc.so which just runs /bin/sh, and use it in the
same way with that same /chroot/bookworm/bin/su binary to gain full
root privileges. I'm not providing actually working PoC here, --
the above command line already tells you that you can control
QEMU_LD_PREFIX which works exactly like LD_LIBRARY_PATH for ld.so,
so qemu will happily run any user-supplied code as root.
This is just a tip of the iceberg - just the very basics. Qemu
can be modified to not react to QEMU_* environment variables when
it detects it is running with elevated privileges, in a way similar
to a shell which ignore certain env vars when run in suid mode -
and this is something which definitely should be done (I'll post
a simpla patch later). Maybe it should produce a big fat warning
when it detects suid mode, too.
The more deep prob is that qemu was never written with any sense
of security in mind, and it is a complex and tricky piece of software,
so making it "secure" is not really an option, at least not in any
reasonable future.
At the very least, I propose to remove --credential option from
scripts/qemu-binfmt-setup.sh entirely (patch will follow) - not to
help someone to shoot themselves in the foot. It should not be
noted in any docs or examples either (how to configure it to work
with suid foreign binaries, that is). Instead, we can add a big
fat warning in the docs which tells the user *not* to try doing
that.
Seeing how much fun can be done with debian systems now before
the yesterday update of qemu-user, I think this issue deserves
much wider attention and care. Thankfully, not every user system
has foreign chroots installed with qemu-user binfmt handler enabled.
Thanks,
/mjt
