Language Selection

English French German Italian Portuguese Spanish

Security: Apple, 'Cloud', Containers and More FUD

Filed under
Security

Container flaw: original message about the security patch

  • CVE-2019-5736: runc container breakout

    Hello,

    I am one of the maintainers of runc (the underlying container runtime
    underneath Docker, cri-o, containerd, Kubernetes, and so on). We
    recently had a vulnerability reported which we have verified and have a
    patch for.

    The researchers who found this vulnerability are:
    * Adam Iwaniuk
    * Borys Popławski

    In addition, Aleksa Sarai (me) discovered that LXC was also vulnerable
    to a more convoluted version of this flaw.

    == OVERVIEW ==

    The vulnerability allows a malicious container to (with minimal user
    interaction) overwrite the host runc binary and thus gain root-level
    code execution on the host. The level of user interaction is being able
    to run any command (it doesn't matter if the command is not
    attacker-controlled) as root within a container in either of these
    contexts:

    * Creating a new container using an attacker-controlled image.
    * Attaching (docker exec) into an existing container which the
    attacker had previous write access to.

    This vulnerability is *not* blocked by the default AppArmor policy, nor
    by the default SELinux policy on Fedora[++] (because container processes
    appear to be running as container_runtime_t). However, it *is* blocked
    through correct use of user namespaces (where the host root is not
    mapped into the container's user namespace).

    Our CVSSv3 vector is (with a score of 7.2):

    AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H

    The assigned CVE for this issue is CVE-2019-5736.

    [++]: This is only the case for the "moby-engine" package on Fedora. The
    "docker" package as well as podman are protected against this
    exploit because they run container processes as container_t.

    == PATCHES ==

    I have attached the relevant patch which fixes this issue. This patch is
    based on HEAD, but the code in libcontainer/nsenter/ changes so
    infrequently that it should apply cleanly to any old version of the runc
    codebase you are dealing with.

    Please note that the patch I have pushed to runc master[1] is a modified
    version of this patch -- even though it is functionally identical
    (though we would recommend using the upstream one if you haven't patched
    using the attached one already).

    == NON-ESSENTIAL EXPLOIT CODE ==

    Several vendors have asked for exploit code to ensure that the patches
    actually solve the issue. Due to the severity of the issue (especially
    for public cloud vendors), we decided to provide the attached exploit
    code. This exploit code was written by me, and is more generic than the
    original exploit code provided by the researchers and works against LXC
    (it could likely be used on other vulnerable runtimes with no
    significant modification). Details on how to use the exploit code are
    provided in the README.

    As per OpenWall rules, this exploit code will be published *publicly* 7
    days after the CRD (which is 2019-02-18). *If you have a container
    runtime, please verify that you are not vulnerable to this issue
    beforehand.*

    == IMPACT ON OTHER PROJECTS ==

    It should be noted that upon further investigation I've discovered that
    LXC has a similar vulnerability, and they have also pushed a similar
    patch[2] which we co-developed. LXC is a bit harder to exploit, but the
    same fundamental flaw exists.

    After some discussion with the systemd-nspawn folks, it appears that
    they aren't vulnerable (because their method of attaching to a container
    uses a different method to LXC and runc).

    I have been contacted by folks from Apache Mesos who said they were also
    vulnerable (I believe just using the exploit code that will be
    provided). It is quite likely that most container runtimes are
    vulnerable to this flaw, unless they took very strange mitigations
    before-hand.

    == OTHER NEWS ==

    We have set up an announcement list for future security vulnerabilities,
    and you can see the process for joining here[3] (it's based on the
    Kubernetes security-announce mailing list). Please join if you
    distribute any container runtimes that depend on runc (or other OCI
    projects).

    [1]: https://github.com/opencontainers/runc/commit/0a8e4117e7f...
    [2]: https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49ba...
    [3]: https://github.com/opencontainers/org/blob/master/securit...

    --
    Aleksa Sarai

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Events: Fedora at CLT 2019, LF's Open Networking Summit and Cloud Foundry Summit on Serverless, Knative, Microservices

  • Fedora will be at CLT 2019
    The Fedora Project will be at the Chemnitzer Linux Tage 2019. So far, Robert Scheck and I will make it happen. As we pretty much did it for the last 10 years.
  • The Linux Foundation Announces the 2019 Open Networking Summit North America Speaking Schedule
    The Linux Foundation, the nonprofit organization enabling mass innovation through open source, has announced the keynote speakers and session line-up for Open Networking Summit North America (ONS), taking place April 3-5 in San Jose, Calif. The full lineup of sessions can be viewed here, and features speakers from AT&T, China Mobile, Ericsson, Google, Huawei, Intel, KPMG, Nokia, Red Hat, Target, and more. “The Open Networking Summit is a chance to bring together the entire open networking community – from telco providers to cloud providers – to share best practices and discuss how we can work together to advance networking technology,” said Arpit Joshipura, General Manager, Networking, Edge & IoT, the Linux Foundation. “Gathering the industry’s foremost innovators and technologists, ONS is a must-attend event for collaboration and knowledge sharing.”
  • 6 Must-Attend Talks at Cloud Foundry Summit on Serverless, Knative, Microservices
    That’s a lot of technical content, so make sure to also get your ideal ratio of business impact content and check out the User Stories track.

Graphics: TuxClocker and VK_EXT_depth_clip_enable

  • TuxClocker: Another GPU Overclocking GUI For Linux
    Adding to the list of third-party GPU overclocking utilities for Linux is TuxClocker, a Qt5-based user-interface currently with support for NVIDIA graphics cards and experimental support for AMD GPUs.  TuxClocker is a Qt5 overclocking tool that supports adjusting not only the memory/core frequencies but also the power limit, fan speed, and other tunables based upon the GPU/driver in use. There is also graph monitors to show the power and temperature limit, where supported, among other features.  TuxClocker offers similar functionality to other third-party, open-source Linux GPU overclocking software though where as most utilities focus just on NVIDIA or AMD hardware, TuxClocker is pursuing both. Currently their stable release supports just NVIDIA GPUs but the development code has AMD Radeon support in the works.
  • Intel Wires VK_EXT_depth_clip_enable Into Their Vulkan Driver, Helping DXVK
    Intel's open-source ANV Vulkan driver now supports the VK_EXT_depth_clip_enable that was designed in part to help the DXVK project for mapping Direct3D atop of the Vulkan API.

Programming Leftovers

  • Packaging PyQt5 apps with fbs
    fbs is a cross-platform PyQt5 packaging system which supports building desktop applications for Windows, Mac and Linux (Ubuntu, Fedora and Arch). Built on top of PyInstaller it wraps some of the rough edges and defines a standard project structure which allows the build process to be entirely automated. The included resource API is particularly useful, simplifying the handling of external data files, images or third-party libraries — a common pain point when bundling apps.
  • Infrastructure monitoring: Defense against surprise downtime
    There are a number of tools available that can build a viable and strong monitoring system. The only decision to make is which to use; your answer lies in what you want to achieve with monitoring as well as various financial and business factors you must consider. While some monitoring tools are proprietary, many open source tools, either unmanaged or community-managed software, will do the job even better than the closed source options. In this article, I will focus on open source tools and how to use them to create a strong monitoring architecture.
  • GSlice considerations and possible improvements
    The paper Mesh: Compacting Memory Management for C/C++ Applications is about moving memory allocations for compaction, even though the memory pointers are exposed. The idea is to merge allocation blocks from different pages that are not overlapping at page offsets, and then letting multiple virtual page pointers point to the same physical page. Some have asked about the applicability to the GSlice allocator.
  • plprofiler – Getting a Handy Tool for Profiling Your PL/pgSQL Code
  • Reading and Writing Files in Python (Guide)
  • Today is a Good Day to Learn Python

Security Leftovers

  • Wi-Fi ‘Hiding’ Inside USB Cable: A New Security Threat On The Rise?
    Today, the world has become heavily reliant on computers owing to the various advantages they offer. It has thus become imperative that we, as users, remain updated about the various threats that can compromise the security of our data and privacy. A recent report published by Hackaday details a new threat that might just compromise the integrity of devices. At first glance, the O.MG cable (Offensive MG Kit) looks like any other USB cable available in the market. It is what lurks within that is a cause for concern.
  • WiFi Hides Inside a USB Cable [Ed: There are far worse things, like USB devices that send a high-voltage payload to burn your whole motherboard. Do not use/insert untrusted devices from dodgy people.]
  • The Insights into Linux Security You May Be Surprised About
    Linux has a strong reputation for being the most secure operating system on the market. It’s been like that for many years, and it doesn’t seem like Windows or macOS are going to overtake it anytime soon. And while the operating system’s reputation is well-deserved, it can also be harmless experienced users. The problem is that some seem to put too much trust in the capabilities of Linux by default. As a result, they often don’t pay enough attention to the manual aspect of their security. Linux can help you automate your workflow to a large extent, but it still requires a manual touch to keep things going well. This is even truer when it comes to security.
  • One Identity Bolsters Unix Security with New Release of Authentication Services
    Unix systems (including Linux and Mac OS), by their very nature, have distinct challenges when it comes to security and administration. Because native Unix-based systems are not linked to one another, each server or OS instance requires its own source of authentication and authorization.
  • Book Review – Linux Basics for Hackers
    With countless job openings and growth with no end in sight, InfoSec is the place to be. Many pose the question, “Where do I start?” Over his years of training hackers and eventual security experts across a wide array of industries and occupations, the author ascertains that one of the biggest hurdles that many up-and-coming professional hackers face is the lack of a foundational knowledge or experience with Linux. In an effort to help new practitioners grow, he made the decision to pen a basic ‘How To’ manual, of sorts, to introduce foundational concepts, commands and tricks in order to provide instruction to ease their transition into the world of Linux. Out of this effort, “Linux Basics for Hackers” was born.
  • Security updates for Wednesday