Nytro Posted April 7, 2019 Report Share Posted April 7, 2019 Assessing Unikernel Security In this “modern” era of software development, the spotlight has bounced from virtual machines on clouds, to containers on clouds, to, currently, container orchestration… on clouds. As the “container wars” rage on, leaving behind multiple evolutionarily (or politically) dead-end implementations, unikernels are on the rise. Unikernels are applications built as specialized, minimal operating systems. While unikernels originated as an academic curiosity in the 90s, the modern crop are primarily focused on running as lightweight paravirtualized guests… on clouds. While some proponents of unikernels consider them to be the successor to containers, the two are, in fact, fairly different beasts with different tradeoffs. While containers make Unix/POSIX the base abstraction for applications, unikernels declare their own. Some unikernels focus on providing varying levels of POSIX compatibility, while others are based around specific programming languages, providing idiomatic APIs for applications written in those languages. However, the core concept of unikernels goes deeper: their main appeal is not the features that they provide, but rather, those that they don’t. Unikernels intentionally omit a great deal of the functionality typically found in full-featured operating systems, which their developers deemed to be not only unnecessary baggage, but also a potential security risk (as their presence substantially increases the system’s attack surface). Furthermore, those developers often attempt to simplify — and even completely reimplement — major OS components such as the network stack, throwing out what supporters call “cruft” and skeptics call “well-tested” or “mature” code. Advocates claim that unikernels are smaller, nimbler, and more secure by virtue of freeing themselves from the shackles of decades-old operating systems code. Such idealized claims are indeed appealing, but are they actually true? Our recently-posted whitepaper covers our initial foray into unikernels and focuses on the native aspects of application security as applied to them. Unikernel applications have a threat model unlike that of normal processes running on a standard operating system, Unix container or otherwise; in unikernels, general application code runs entirely within kernel space. We begin the whitepaper by describing the general threat model of unikernels as compared to that of containers. We then describe several relevant core security features and exploitation mitigations both within and provided by modern operating systems and build toolchains, and explore how these may apply to unikernels. This forms the basis of our methodology for assessing the general correctness and safety of unikernels. We go on to apply this testing methodology to two major open-source unikernel projects, Rumprun and IncludeOS. For each unikernel, we provide a suite of test cases to invoke and identify relevant security protections, and dig into their source and compiled code to uncover further issues. We also discuss unikernel-specific exploitation techniques and provide example exploit code for common memory corruption vulnerabilities. The presence of these vulnerability classes would enable reliable blind remote exploitation; that is, an attacker could gain arbitrary code execution in ring 0 without any direct knowledge of either the source code or the binary. Other notable vulnerabilities include a brute-force attack that takes advantage of unikernels’ ability to restart almost instantly, and a stack overflow that is able to stomp over the very copy instruction that caused it due to unusual section ordering. We then document a number of remediation and hardening recommendations for each unikernel and document our disclosure interactions with each project. As part of the latter, we assess the upstream patches made in response to our findings and recommendations. We introduce a series of our own patches that remediate a number of the issues we identified in Rumprun, many of which apply more generally to the Xen Mini-OS kernel on which it is based. These can be found here,1 here,2 and here.3 To conclude, we contrast the proclaimed security benefits of unikernels with our actual results. We also briefly describe our current and future research into the security pitfalls of another oft-touted “security feature” of unikernels: the complete reimplementation of mature, external-facing OS components such as the network stack. Even if this process does simplify and modernize the relevant code, as unikernel proponents claim, it also throws out decades of edge-case handling and security fixes that have accreted in response to security vulnerabilities. We are concerned that such re-implementation efforts do not show appropriate respect to the maturity of such codebases, and in doing so may reopen Pandora’s box. As a side note, we will shortly announce several issues that we identified in the MirageOS unikernel but did not cover in our ToorCon XX talk due to disclosure timelines. NCC Group regularly performs a large number of engagements assessing the security and hardening of applications and services, and the platforms they run on, in, and under, including containers, clouds, PaaSes, embedded runtimes, and specialized sandboxes, to name a few. The authors were drawn to this research by the potential and promise unikernel technology (still) has to build lightweight, performant, robust, and secure services in fundamentally new ways. If you’re building any of the above, especially anything unikernel-based, we’d love to help. https://github.com/nccgroup/rumprun↩ https://github.com/nccgroup/src-netbsd↩ https://github.com/nccgroup/buildrump.sh↩ Published date: 02 April 2019 Written by: Jeff Dileo and Spencer Michaels Sursa: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/april/assessing-unikernel-security/ Quote Link to comment Share on other sites More sharing options...
