QEMU: out-of-bounds memory access issue | Hacker News Reader

QEMU: out-of-bounds memory access issue

access.redhat.com

47 pointsconductor58 comments

> 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.

Sounds similar to OpenBSD's `pledge`, a system call that a process can use to tell the system which minimum privileges it needs, so that a buffer overflow exploit has less of a chance of running amok (depending on the program). It's new in 5.9 and most of the base system and a bunch of ports (including Chromium) have been updated to make use of it.

Of course, it doesn't completely prevent someone from doing something nasty, but it does force them to be much more targeted in which programs they can attack. Every little thing helps a little bit, and it all adds up.

My issue with pledge is that it doesn't get applied to the new process on exec. This makes it essentially useless for a program that needs to start any other programs to do it's job.

Seccomp is quite cool because it lets you filter syscalls and then there's no way for you to disable the filtering (assuming no bugs in the implementation).

Then again, any program that in any way starts another binary (or several) would always end up having to pledge the sum of all possible child permissions, so it would just mean that any such program (like sudo) would just not be limited at all just so it can run both ls and reboot, when the setuid sudo program would be just the kind of program you would like to have pledged so that it doesn't talk net when it shouldn't or does other out of line weirdness.

Right, so then sudo could conditionally pledge things based on what its ACL says. And that whitelist would apply to the program it starts. I'd understand there being "temporary" pledges, where it gets reset on exec, but I don't understand making it by default temporary.

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

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).

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.

We need emulators written in safe languages.

I guess you're the first to volunteer then! :D

No, no no, when someone says that, they're telling other people to do that work.

Or in this case, not. https://github.com/ianopolous/JPC

I thought it had to be a safe language rather than a 0-day hoarding platform. :P

Least you did your part getting us a start on it. It could be ported to a simpler, safer language and runtime.

I'll bite. :-) Java is a perfectly safe language, with one of the best defined specs out there. The JVM, however, has had it's share of vulnerabilities, but that comes with the territory of being installed on 3 billion devices.

I'll be nice since you are. Java is well-defined language with safety features. Problem was it's written for inefficient abstract machine hard to implement correctly and with much complexity. That and its libraries are written in an unsafe language.

Whereas, languages like Modula-3, Ada, or safe variants of C are straight-forward to map to real hardware with small to no runtimes and libraries in same language. Many checks in by default. Two, C subsets and SPARK, can be proven free of common errors.

There's a vast difference in safety between such languages and the Java platform. Complexity of compiler/runtime and unsafe libraries are main reasons. Safety-critical, minimal runtimes exist for Java but they're slow and I doubt you paid $$$ for them. ;)

What's your opinion of the Graal substrate VM? It is 98% implemented in Java, allows you to precompile a VM exactly for your language, and allows you to exclude the entire Java core libraries, for a super lean, but still highly optimized and safe runtime.

I look at it tonight when I'm off. Already sounds better than regular platform.

Damn, had I had this link...

http://lafo.ssw.uni-linz.ac.at/papers/2015_CGO_Graal.pdf

...I could've replied immediately. Graal keeps HotSpot VM, presumably libraries too, while replacing the JIT with an extra-aggressive one (semantic risk) coded in Java (lower code-risk). It's still bad as it barely addresses platform's overall risk. Might make a better, safer JIT for existing platform.

The [potentially] better ones are those designed for high-reliability applications such as Aonix's PERC and JamaicaVM. They tend to try to do less with more predictability. There was one implemented on Oberon called Jaos JVM. Also, although JVM itself is orthogonal to this, you can run your Java program on JX Operating System for higher security.

http://www4.cs.fau.de/Projects/JX/

Thanks! JX looks very interesting!

I double checked and it appears that almost all of the Java core libraries (rt.jar) are indeed already written in Java. (More a point of information than anything else)

I thought you'd like it. It's GPL'd, too, with active development. Might be worth contributing to or porting to Xen for containerized apps with better security.

And digging deeper, the Hotspot VM has ~250k lines of C/C++. This provides:

1) Class loader

2) Bytecode interpreter

3) 2 JITs

4) 3 Garbage collectors

5) High performance synchronization primitives

My understanding is that the aim of Graal is to replace the JITs, that Truffle will replace (1) and (2) and the Substrate VM will replace (4) and (5).

So most of the C/C++ should disappear. (I don't know what the substrate VM is written in, but it is much smaller regardless)

Going by this presentation after reading the Graal slides:

http://www.oracle.com/technetwork/java/jvmls2013wimmer-20140...

The documentation of all of them is terrible as there's no clear explanation of Truffle and Substrate: jumps right into technical stuff with a barrage of techniques. Truffle appears to be a toolkit for generating parsers/compilers plus integration interface for the VM's. I don't see mention of replacing class loader and bytecode interpreter. Whereas Graal is a combo, per slide images, of Hotspot bottom parts and Java-based compiler/JIT. It at least has huge code reduction plus safer code over original VM in their illustrations. Only 60Kloc.

Going from there, the linked PDF shows Truffle connecting to either GraalVM or Substrate VM. In one slide, it references GraalVM like it's necessary for integrating with Java applications while calling Substrate embeddable. Makes me think Substrate is standalone apps. In another slide, it visually implies that Substrate compiles your code and just Java classes you need into one executable that maybe can't load others. It's not clear if Substrate is reusing the C/C++ code of 1, 2, 4, or 5 from HotSpot for lower layers.

All in all, they're doing interesting things but I'm too confused to evaluate them. Do you have any links that are more specific on these issues, esp how SubstrateVM works or whether Graal uses C/C++ code for bottom layers as in picture? I can't evaluate them without even an internal architecture description.

That has to feel pretty good. This reminds me of the cpercival exchange way back when. It's funny to see people set themselves up like that in this community.

Hello! A good chunk of the users of this site build stuff for a living and for fun!

This reminds me of the cpercival exchange way back when. It's funny to see people set themselves up like that in this community.

Just to be clear, I didn't set that up. In fact I was rather amazed at that question arriving in my lap.

No, I didn't mean you, I meant the person asking the question. It's a similar situation because the guy above assumed ianopolous was just complaining and didn't have any skin in the game.

Ah, got it. Thanks for the clarification.

Well done. That was "Did you win the Putnam"-esque

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.)

Ada, FreePascal, ...?

Problem is that when you use C you get the low level coders on board relatively easily. Not always the case in other languages

When I started programming, C was just yet another systems programming language.

Low level coders were using straight Assembly.

I find ironic to see such statements about 40 years later.

Then Cyclone or any of safe C subsets/variants.

Cyclone is no longer active last time I checked. Or is it?

What other safe C subsets/variants are out there which are actively being worked on?

Cyclone and bit-c interested me greatly so pointers would be appreciated.

The author of Cyclone seems to suggest that Rust is the current path forward: http://trevorjim.com/unfrozen-cyclone/

> Cyclone was an early attempt to create a programming language at the level of C, combining manual memory management with complete static memory safety. You can think of it as one step on the path that Rust and other languages have continued, one that I believe will eventually replace C, eliminating a host of severe security problems.

Cyclone, particularly its memory management, was one of the inspirations for Rust. That said, there's no way in hell Rust is a C replacement for people sold on C itself. There's people that need safe, fast, systems code. Rust can probably handle that. Then, there's people that think C is best language or don't want to learn something too different. They're not switching to Rust under any circumstances. The safer C's are useful for those people.

Still have to force or pay them to do it as the C zeal is so strong. Yet, the smaller the adjustment, the more likely the uptake. Worked for C and Java vs others that clean-slated things.

It's not. Like most of academic ones, it can be picked up or clean-slated if people really want it. The authors tend to move on, though, as in BitC (unfortunately...). I have some others for you, though. Most research is on automatically transforming C instead of a safer, manually-done C. Best are these:

https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/

http://sva.cs.illinois.edu/downloads.html

http://dslab.epfl.ch/proj/cpi/

Paper mentioning several of the safe C's, including those like Vault you can't have:

https://pdfs.semanticscholar.org/a890/a850dc78e65e26f8f4def4...

Galois, as usual, graciously open-sourced two of theirs (Ivory & Tower) that's already fielded in real world:

http://ivorylang.org/

Popcorn and TALC are older ones in prototype form:

https://www.cs.cornell.edu/talc/releases.html

Someone here showed me this one I haven't evaluated but is used in compiler front-end:

https://eigenstate.org/myrddin/

The C0 one used in Verisoft is embedded in vc0compiler-trunk probably. They did great things with it but I haven't been brave enough to try to retrieve it ;).

http://www.verisoft.de/VerisoftRepository.html

So, altogether, what remains is quite scattered and prototype form. Plus, you still have to rewrite the software. So, I've mostly been recommending people apply Softbound, SAFECode, and CPI to their code just to see what happens. If it still works and fast enough, then just use it as it covers most bases. Also, contributing to those three's codebase is a very, wise move with potentially large impact.

I have a long-term experiment to implement KVM in Rust. Adding union support to Rust was the first step: https://github.com/rust-lang/rfcs/pull/1444

Hey, great idea. I'm still a bit of a Rust newb but I'm interested in helping if you have a starting point. Otherwise, I'll start looking into it myself.

The /dev/kvm API has a hard dependency on union support, and rustc hasn't yet implemented RFC1444, so I hadn't planned to attempt to create a KVM crate until that point. Once that happens, I'll start building prototypes and pushing them to github and Cargo.

In the meantime, here's an article I wrote on the /dev/kvm API, including how to drive it directly from a small C program: https://lwn.net/Articles/658511/ (edit: fixed URL)

I think you meant to link to https://lwn.net/Articles/658511/

Why can't we just alias the storage to something different underneath? How is there a "hard" requirement? Unless it's difficult/impossible to make the representation align correctly without the same semantics?

The main data structure for /dev/kvm is `struct kvm_run`, which includes a massive union. There are also unions spread out across the rest of the API; half the structures in the API have some kind of union in them. It would be possible to make that work using unsafe operations like `std::mem::transmute` and careful manual pointer offsets, but that would eliminate much of the benefit of doing this in Rust in the first place.

Sounds like common lisp might be what you are looking for then (depending on what you think "interoperable at a C ABI level" exactly entails I suppose. https://common-lisp.net/project/ecl/main.html)

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.)

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 | sh` does not count)

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.

Several linuxes have packages in their repositories today, and we're working on fixing the issues for the ones that haven't yet.

Firefox now has Rust code in it, so any distro that compiles from source and has Firefox is gonna end up packaging rustc too.

Yeah, Rust is pretty high on the list of candidates, but for instance there is no rust compiler shipped by default in Debian stable, so I don't think it meets "widespread distro support" yet. Also https://doc.rust-lang.org/book/getting-started.html says that everything not x86 is at best only in tier 2 "guaranteed to build", which is not really great on the "support multiple architectures" front; and lack of s390x host support would be a dealbreaker (it's a firmly supported host for running KVM on).

> 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 is something to be said for replacing C and old C++ code with C++11 and the safer new constructs like std::unique_ptr. It doesn't stop you from doing unsafe things but it makes it much easier not to, without requiring a complete rewrite.

There's a big difference between "easy to use" and "hard to misuse". The problem with C++11 or C++14 is that, for all their additional features, you're still just one cast away from a bug like this.

unique_ptr isn't safe, and it doesn't provide any safety that you didn't have with smart pointers in earlier versions of C++.

In fact, I'm even skeptical of the claim that unique_ptr provides significant security benefits over malloc and free. Leaks aren't the kinds of security problems we're talking about here.

This isn't true - unique_ptr provides protection against Use after Free which is one of the most common memory corruption vulnerabilities in modern applications.

No, it doesn't. There are many ways to get use after free using unique_ptr combined with references or this pointers.

Protection != prevention

I don't know what this means, but if you're implying that unique_ptr is good enough to prevent use after free in practice, that is obviously empirically false. Every browser engine, for example, uses C++11 and regularly has exploitable use after free.

There's work on it in the verification community but not quite a full emulator yet. Is work on various pieces though. Meanwhile, separation kernels like seL4 and verified hypervisors like NOVA/Seoul can reduce risks.

What would the performance penalty be?

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

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

For the fixed RHEL RPM, see: https://access.redhat.com/security/cve/cve-2016-3710

Reply on news.ycombinator.com