An article was shared yesterday detailing a runC vulnerability that affects Docker and Kubernetes where a malicious container can overwrite a host system’s runC binary, thus allowing root-level code execution on the host. This is an operations nightmare and it made me think of how Chef Habitat can help in these situations. I’d like to give a high-level overview of how to apply defense-in-depth philosophy with Habitat and help you prevent or address these kinds of vulnerabilities in the future.
Containerizing our applications is a fantastic way to help drive business value by reducing overall friction in the software development life cycle. However, it’s important to maintain responsible practices that mitigate risk and limit the scope of vulnerabilities that all too often exist in production.
Whenever we see something like a runC vulnerability escape into the wild, an opportunity arises to examine and shore up the assumptions and the processes we use to deliver our software. One of the fundamental design principles of Habitat is to enable a build process where all of the software running as part of an application deployment is clearly defined in an easy-to-audit fashion (read: in code). In our IT organizations, we should have the goal of building, releasing, and managing our applications in this “as code” manner. This enables us to use peer review, automated testing, security analysis, and other tools earlier in the development cycle to ensure our code is of the highest quality by the time it hits production. Then, when the next “Doomsday” vulnerability in our code or dependencies is released, we’re able to get a patch through the pipeline and released as quickly and safely as possible. Habitat’s well-defined build, release, and manage lifecycle is designed to allow teams to leverage outside tooling at appropriate times at each stage of the lifecycle.
As the Vaughn-Nichols article indicates, there exists a tendency early in the container adoption phase to use the first image found on a public registry that suits the development need. I’ve observed this first hand where applications are running in production that rely on containers from public registries that haven’t been subjected to sufficient scrutiny. It can be difficult for the sources of even the most well-built and publicly available containers to convey any inherent risk associated with consuming their artifacts. However, when you use Habitat, you’re able to establish an explicit chain of trust between the applications running in your environment and the validated code as it exists in your repositories. This can be done for your own code as well as the core plans provided by Chef, as each plan in the dependency tree clearly describes its source.
Here are some pointers on how we can use Chef Habitat in conjunction with security tooling at different phases of an application’s lifecycle:
It’s important to note that the Habitat Supervisor does not make use of runC, therefore this vulnerability (CVE-2019-5736) has no impact to applications managed directly by Habitat. However, if you use Habitat to export a Docker or Kubernetes artifact containing your application, you’ll want to ensure that the host system with the respective container runtime has the patched version of runC.
Ultimately, vulnerabilities like the one uncovered in runC can contribute to organizations’ hesitation to fully embrace new technologies or practices. The question becomes whether the benefits of an emerging paradigm will be outweighed by the potential risks of blazing a trail in largely uncharted territory. Habitat helps you meet these challenges head-on, by providing facilities for packaging the applications that drive your business in a truly platform-independent way. This gives you the flexibility to adapt to whatever surprises a rapidly changing technical landscape might throw at you, without sacrificing the velocity with which your teams can innovate.
Head over to our site to find out more about how Chef Habitat can help you build hardened and auditable applications regardless of the container environment. To hear more about Habitat’s capabilities and the development lifecycle, contact us.
Special acknowledgments to Rob Campbell and Nick Rycar.