Amazon employee here: we have released a security bulletin covering how to update to the latest patched Docker on Amazon Linux, Amazon ECS, Amazon EKS, AWS Fargate, AWS IoT Greengrass, AWS Batch, AWS Elastic Beanstalk, AWS Cloud9, AWS SageMaker, AWS RoboMaker, and AWS Deep Learning AMI.<p>Please check out the bulletin and update if you are using one of these services.<p><a href="https://aws.amazon.com/security/security-bulletins/AWS-2019-002/" rel="nofollow">https://aws.amazon.com/security/security-bulletins/AWS-2019-...</a>
Hey all - Seth from Google here. Please let us know if you have any questions regarding GKE or questions about the upgrade process. I'm also happy to escalate any feedback to our internal product and engineering teams.<p>Here's link to our security posting with more information and upgrade procedures: <a href="https://cloud.google.com/kubernetes-engine/docs/security-bulletins#february-11-2019-runc" rel="nofollow">https://cloud.google.com/kubernetes-engine/docs/security-bul...</a>
> However, it <i>is</i> blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace).<p>In other words, this won't affect anyone who understands the implications of running a process as root. Unfortunately, the sad truth is that most people I've come across who have "lots of experience" with implementing Docker containers, do not even understand the basics of how they work, let alone the implications of root access. I've interviewed candidates who claim to know Docker but can't even tell me how Docker differs from traditional virtualisation or how it achieves its isolation. The best explanation that most of them come up with is, "Docker containers are more lightweight".<p>This sort of vulnerability should have been a non-issue but it has gained attention due to the sheer amount of incorrectly configured containers in the wild. This was an accident waiting to happen, and I doubt we've heard the last of this sort of thing.
Looks like Docker 18.09.2 was released a few minutes ago to address this: <a href="https://github.com/docker/docker-ce/releases" rel="nofollow">https://github.com/docker/docker-ce/releases</a>
Red Hat’s page on the vulnerability: <a href="https://access.redhat.com/security/vulnerabilities/runcescape" rel="nofollow">https://access.redhat.com/security/vulnerabilities/runcescap...</a><p>RH CVE page, with the vulnerability’s metrics and the list of RH packages affected (plus links to the errata pages that have details on fixed builds): <a href="https://access.redhat.com/security/cve/cve-2019-5736" rel="nofollow">https://access.redhat.com/security/cve/cve-2019-5736</a>
There are nearly 4,000 exposed Docker daemons: <a href="https://www.shodan.io/report/ol761bRb" rel="nofollow">https://www.shodan.io/report/ol761bRb</a>
For better isolation check out KataContainers: <a href="https://github.com/kata-containers/runtime" rel="nofollow">https://github.com/kata-containers/runtime</a><p>It's a drop-in replacement for runc. With KataContainers it runs docker containers in a lightweight VM so you get all the security benefits of a VM. The downside is slightly slower container start up times and might not work in nested virtualized environments.
Debian’s security tracker, showing the affected versions, and (when available) the fixed versions: <a href="https://security-tracker.debian.org/tracker/CVE-2019-5736" rel="nofollow">https://security-tracker.debian.org/tracker/CVE-2019-5736</a><p>And Ubuntu’s: <a href="https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-5736.html" rel="nofollow">https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...</a><p>Personally, I like these vs. RHEL, since all the info is on page.
The vulnerability description seems to be lacking an explanation why the /proc/$PID/exe symlink is so special and why using the #!/proc/self/exe hashbang will work while using #!/usr/sbin/runc probably won't. Am I right that the proc filesystem in proc_exe_link() fills the file_operations struct in a way that causes open() not to go through a dereferencing procedure using the filesystem but just open the file used to run the executable?
The best fix is to upgrade to 18.09.2. For those that can't do that immediately, backported versions of runc for Docker releases going back to 1.12.6 are available from Rancher at <a href="https://github.com/rancher/runc-cve" rel="nofollow">https://github.com/rancher/runc-cve</a>. But please only do that as a temporary workaround until you can properly upgrade to 18.09.2.<p>Please patch if you don't 100% trust all users on your host.
Mesosphere employee here. We have released the product advisory on this CVE. Please check out the advisory and update your software.<p><a href="https://support.mesosphere.com/s/article/Known-Issue-Container-Runtime-Vulnerability-MSPH-2019-0003" rel="nofollow">https://support.mesosphere.com/s/article/Known-Issue-Contain...</a>
Next year this exploit will still be in thousands if not millions of containers all over<p>There is a distinct lack of knowledge on how to manage a system in the container ecosystem
Not that this shouldn't be patched and all, but this seems like it is being treated with more urgency that is required.<p>If I am understanding the CVE correctly, you need to be able to launch <i>privileged</i> containers with an attacker-controlled image where the container user is root <i>and</i> not namespaced (i.e., the same root as the outside root user). How is this not "on the wrong side of an airtight hatch[1]"?<p>Am I missing something here? If you can start privileged containers, why not just execute evil.exe directly?<p>[1]: <a href="https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283" rel="nofollow">https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...</a>
Is this something that non-privileged containers mitigates? Curious what the big barriers are to this. I know they exist, but aren't used widely...I assume because some functionality doesn't work.
Yikes that's a big patch! Just on a meta-level, security vulnerabilities fixed with big patches are usually the least fun.<p>Also, I would bet that freshly written C code has about 1 RCE bug every 100 LoC. This patch has 236 LoCs so probably about 2.36 RCE's.