
QEMU: out-of-bounds memory access issue - conductor
https://access.redhat.com/blogs/766093/posts/2309211
======
wyldfire
> The sVirt and Seccomp functionalities used to restrict host's QEMU process
> privileges and resource access might mitigate the impact of successful
> exploitation of this issue.

seccomp is pretty awesome IMO. Would that more software opted in to dropping
unneeded system access.

~~~
aseipp
I agree in general. But in this case - look at the actual source code:

[https://github.com/qemu/qemu/blob/master/qemu-
seccomp.c](https://github.com/qemu/qemu/blob/master/qemu-seccomp.c)

There's also no further refinement of seccomp privileges at runtime, so that
list of syscalls is statically whitelisted up front and nothing else is done
(search 'seccomp' in the repository). Is there anything I obviously _couldn
't_ achieve with that list of syscalls?

Given the list of what's whitelisted for the whole process, I wouldn't put
much stock in it, for now. qemu would probably need some real upgrades and
significant work to make this more fine grained and reduce the attack surface
using it (both against the kernel and for rogue programs attacking the host
qemu instance itself).

~~~
wyldfire
You're right, I hadn't checked this list. If open() were missing from the list
it might be much harder to do damage outside the current VM. It's the most
critical one in this whitelist IMO. Many/most of the remaining would have
their scope limited to currently open fds/this-process' maps/segments.

------
ianopolous
We need emulators written in safe languages.

~~~
pm215
I'd love QEMU to move to some safer language. Unfortunately I don't know any
which meet the necessary criteria: \- support linux, osx, windows \- mature
enough for widespread support in distros \- support at least half a dozen
different host cpu architectures \- simply interoperable at a C ABI level so
you can move parts of the system to the new language without doing a 100%
rewrite

(There are probably other requirements too but that last one is the biggie
really.)

~~~
pcwalton
Which of these is Rust missing?

(Though I should caution that it's not as simple as "just write in a safe
language" if you're doing the tricks that QEMU does for speed. That's not to
say we shouldn't be moving away from C and C++ in general, however--we
should.)

~~~
dijit
last time I deployed a compiler to a machine in a _reliable_ way it took 45
minutes and a lot of document reading.

Rust is not ready for linux yet.

(no, `curl -sSf [https://static.rust-lang.org/rustup.sh](https://static.rust-
lang.org/rustup.sh) | sh` does not count)

~~~
duaneb
I dunno, 45 minutes doesn't seem that bad for a manual deployment from scratch
including documentation reading. The equivalent with gcc would be days of
work.

------
zymhan
So there isn't a patch for this yet it seems?

~~~
lfam
It's fixed in 2.5.1.1:
[http://git.qemu.org/?p=qemu.git;a=log;h=refs/tags/v2.5.1.1](http://git.qemu.org/?p=qemu.git;a=log;h=refs/tags/v2.5.1.1)

