New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blogpost: Unbreakable unikernels. #45

Merged
merged 7 commits into from Jul 10, 2017

Conversation

Projects
None yet
6 participants
@perbu
Copy link
Contributor

perbu commented Jul 7, 2017

Unikernel security considerations.


A key feature of a unikernel system is that it is immutable. Once it boots there is typically no need to update it. If the VM runs in ring 3 it is incapable of modifying its own page tables. A unikernel setup to run in ring 3 is, as far as I can tell, impregnable. The CPU will refuse to alter anything executable.

This means that the hypervisor must load the unikernel and set the executable pages immutable before booting it. Now the VM is incapable of modifying itself. Basically it is unassailable - it is impossible to compromise without access to the VMM. If the application has a bug you might still be able to crash it and make it restart, but you have no way of subjugating the VM.

This comment has been minimized.

@avsm

avsm Jul 7, 2017

section 2.2.3 of http://anil.recoil.org/papers/2013-asplos-mirage.pdf discusses some aspects of this. In PV mode, it's also possible (via a hypervisor patch since it never did upstreamed to xen) to prevent executable mappings. We just have to setup the device rings before this, as you describe above. The basic architecture of this is similar to other privilege dropping approaches in userspace (e.g. openbsd pledge)

"unassailable" is still a bold claim though :-) It might be more accurate to say that the aperture of attack is significantly reduces -- to the hvm fault handler in the hypervisor. It's also important to make sure that there are no executable and writable pages, but that is fairly easy on modern language runtimes.


These interfaces pose a risk to the VMM. As shown by the [2015 VENOM attack](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456) they can be used to break out of a VM and into the VMM. In the VENOM attack the attacker could attack the [Qemu] through the floppy interface provided by it.

IBM research has spearheaded this effort with their [Ukvm] project. Ukvm is a replacement for [Qemu] specifically built for unikernels. [Solo5] provides a framework for Unikernels to boot a VM that is backed by ukvm instead of qemu. Both [IncludeOS] and [MirageOS] are already capable of booting using the Solo5 core and efforts are underway to port [HaLVM] to Solo5/Ukvm.

This comment has been minimized.

@avsm

avsm Jul 7, 2017

There is also a Meun port: Solo5/solo5#190

@avsm

This comment has been minimized.

Copy link

avsm commented Jul 7, 2017

lgtm! cc @samoht as @amirmc is on holiday

@hannesm

This comment has been minimized.

Copy link

hannesm commented Jul 7, 2017

Thank you for writing this article. I'm a bit sceptical, and would be a bit more cautious (and bring up more concrete facts) about claims of security. A random set of talking points below:

  • I miss some actual numbers from the blog post (i.e. X % of the code base of a standard linux VM/container) - you may want to read in more detail section 7.2 of our nqsb-tls paper, esp the pieces on page 13 starting with "the bitcoin pinata" -- maybe evaluating the trusted code base of includeos using actual numbers (binary size, lines of code) would be beneficial for this article?
  • "exploits usually require a shell" - I'm really not sure how this is related. if you get remote code execution, the "there is no shell" argument sounds weird to me - if you can upload code into a unikernel, you can use the unikernel for your purposes (DoS, data exfiltration, ...). surely, a unikernel contains only its required functionality, and thus an attacker will have to upload more code if they need additional functionality.
  • unikernel security is worse than openbsd/linux from some point of view: unikernels run in a single address space and in ring 0. I haven't seen any unikernels having defenses such as KARL or ASLR -- this means that once you found an issue with a unikernel it is trivial to get a reliable working exploit (since memory mappings etc. are static)
  • the immutability (no access to persistent storage in the common case) is nice - an attacker cannot (easily?) exploit a unikernel once and have a reboot-safe "rootkit" on the server
  • please don't use "unbreakable". just don't. it'll be used against you in the future. there's no system which has 100% security
  • you may be interested in reading through our mirage-net-xen bug and its connected blog article

EDIT: sorry if that sound rude, didn't mean it. and of course you can publish any contents to the Internet, I'm only very keen in being honest about sensible aspects such as security (which is very close to my heart).

@perbu

This comment has been minimized.

Copy link
Contributor

perbu commented Jul 7, 2017

Hi Hannes.

Thanks for the honest feedback. I can take it and it is a goal in itself for us to agree on what is true and what isn't true on how unikernels are portrayed. I've surely had rougher feedback.

While I agree that making hyperbolical claims isn't typically good I'm not sure if it is bad here. There seem to be a tradition in unikernel land with outlandish claims in various blogposts ("Unikernels will kill containers in five years", "Unikernels are unfit for production", etc) so I wrote it with that tone in mind.

The shell argument is really just the "no syscalls" argument rehashed. The shell is a nice fixture when attacking. I'll have a look at it.

While the address space of IncludeOS isn't dynamically randomized it is randomized on each build. So when we're using our own tools to deploy multiple instances of the same application the address space will look different on each one (we run through the linked for configuration changes).. So having access to the source gives you little insight into the memory layout of the binary. You'll need the exact binary to figure out how to call something (we've sacrificed LTO to be able to do this). I guess ASLR is typically dynamic, but I think we're pretty close to it.

Yeah. We're all currently running in ring 0. However, I fail to see why that makes anything less secure. Moving something into ring 3 doesn't really change much. On a Unix system it changes things as the attack can be persisted - but in a unikernel which ring you're in is not really that important.

Lastly. Unbreakable or not. I know it sounds cocky af and perhaps I've been hanging out too much with ppl from the other side of the pond, but I really struggle to see how a Unikernel, running with immutable pages can be subverted. But you're right in that it might still be subject to other attacks (such as the one you've linked to and heartbleed ofc) and perhaps that is what you had in mind. So I agree that you could say that an exploit into confidentiality would "break" the system.

@hannesm

This comment has been minimized.

Copy link

hannesm commented Jul 7, 2017

@amirmc

This comment has been minimized.

Copy link
Contributor

amirmc commented Jul 10, 2017

Thanks for the comments here folks! I'm planning to merge this post later today. It would be great to continue discussion and I'll open a thread on devel.unikernel.org once the post is live (I'll post a link here too).

@perbu, there are a few typos and sentence changes I'll make post-merge (for clarity). I hope that's ok.

@mato

This comment has been minimized.

Copy link
Contributor

mato commented Jul 10, 2017

@perbu A couple of minor comments (arriving late to the discussion):

  • Regarding VMCALL as a hypercall mechanism (guest to monitor) on x86, this is not usable on (at least) KVM since the kernel-side hypervisor code uses this instruction for its own purposes. This is why ukvm uses PIO instructions to invoke hypercalls on x86.
  • Regarding Ring 0 vs. Ring 3, running in Ring 3 is one way to get immutable page tables. There are other ways which I have not yet explored but could achieve the same effect while allowing guests to run in Ring 0. Aside from the question of immutable page tables I don't see any other downsides to running in Ring 0.
  • I agree with @hannesm that with claims about security, the devil is in the details and "hyperbolic" or "absolute" statements are best avoided.
@perbu

This comment has been minimized.

Copy link
Contributor

perbu commented Jul 10, 2017

@amirmc amirmc merged commit 403b648 into Unikernel-Systems:gh-pages Jul 10, 2017

@amirmc

This comment has been minimized.

Copy link
Contributor

amirmc commented Jul 10, 2017

This is now merged and I've opened a forum thread at: https://devel.unikernel.org/t/unikernels-are-secure-here-is-why/258

Thank you for the post, @perbu!

@thestinger

This comment has been minimized.

Copy link

thestinger commented Jul 10, 2017

"As long as there are no writeable and executable pages in the unikernel I’m strugling to see a way it can be subverted."

So you're making a strongly opinionated post about security but aren't familiar with hijacking control flow (ROP / JOP)? I don't disagree with the premise which made it all the more frustrating to read this. You're also greatly overestimating the benefits of ASLR, especially only build-time ASLR. The post also doesn't inspire much confidence that it's a proper implementation of even build-time ASLR (i.e. high entropy base offsets, not shuffling things around in a random order) if you don't know about the attacks it's meant to counter.

@perbu

This comment has been minimized.

Copy link
Contributor

perbu commented Jul 10, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment