On 8/24/25 12:16, Michael Tokarev wrote:
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.
I really disagree on this.
There are very good reasons to have qemu with credentials enabled.
One such valid example is to used debian as buildd server to cross-compile
debian packages for other architectures. For this you need to have
credentials enabled for quite some packages, so with security in mind
you should normally not allow other users to access the machine.
In general, just if someone can shoot himself into the foot you should
not remove features.
Instead, disabling it by default, and adding a big fat warning if people
enable it is a good way forward.
It should not be noted in any docs or examples either (how to
configure it to work with suid foreign binaries, that is).
Disagree. Hiding issues don't solve them.
Instead, we can add a big fat warning in the docs which tells the
user *not* to try doing that.
Yes. Agreed.
Helge
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
