A serious vulnerability in runC, a tool used to spawn and run Linux containers, allows attackers to break out of containerized environments and gain full access to the underlying servers.
RunC is a container runtime that makes use of Linux’s built-in capabilities to create sandboxes in which applications can run. A server can have hundreds of applications or microservices, each running in its own container.
The new vulnerability has been dubbed runcescape and is tracked as CVE-2019-5736. It was found by researchers Adam Iwaniuk and Borys Popławski and was reported to the Open Containers Security Team.
Because it is located in runC, the flaw also affects all container engines that depend on this component, including the popular Docker platform. As its name implies, the vulnerability allows an attacker with access to a container to escape from it and gain root access on the host server. That’s because runC is tightly integrated with the Linux kernel.
Flaws that allow escaping from virtual machines, containers or other kinds of sandboxed environments defeat the very purpose of those technologies, which is to keep potentially vulnerable applications separate from the trusted code base—the operating system. This has strong benefits for security and is what made the rapid development of cloud infrastructure possible.
Because it requires an attacker to have access to a container first, this vulnerability has received a score of 7.2 out of 10 on the CVSS scale, which means a severity risk of important rather than critical. However, there are thousands of publicly exposed Docker deployments and container management systems out on the internet that are at immediate risk.
“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),” said Aleksa Sarai, one of the runC maintainers, on the Openwall security mailing list. “However, it *is* blocked through correct use of user namespaces (where the host root is not mapped into the container’s user namespace).”
Also, the attack is not possible on systems that have the SELinux security mechanism enabled and in enforcing mode, such as Red Hat Enterprise Linux or Red Hat OpenShift.
Micropatch Available for Adobe Reader Zero-Day Flaw
Security researchers from 0patch.com have developed a micropatch for an unpatched vulnerability in Adobe Reader that allows maliciously crafted PDF files to automatically send NTLM credentials back to attackers.
The vulnerability was disclosed last month by researcher Alex Inführ and is similar to one found last year by researchers from Check Point Software Technologies. That older flaw was dubbed BadPDF (CVE-2018-4993) and allowed a PDF file to make a callback without user interaction to an attacker’s remote SMB server and leak NTLMv2 credentials. NTLM is the authentication mechanism used on Windows networks.
Inführ’s technique abuses the xml-stylesheet feature of the XML Form Architecture (XFA), an XML structure that’s used to define forms and other elements inside a PDF. His proof-of-concept exploit can send requests over SMB or WebDAV.
“Adobe Reader actually detects any http/https URLs specified in a xml-stylesheet element and asks for the user’s confirmation,” the researcher said in his blog disclosure. “This dialog can be simply bypassed by using UNC paths.”
Since Adobe hasn’t yet fixed the vulnerability, researchers from 0patch.com devised an in-memory patch that extends Adobe’s fix for the earlier callback flaw.
“The Reader already implies the correct behavior by showing a security warning on loading a remote style sheet via HTTP, so we decided to add our own security warning for loading style sheets via UNC as well,” Mitja Kolsek from the 0patch team, said in a blog post.