An attacker must have root privileges inside the container to access necessary resources — running privileged container, misconfiguration, and privilege escalation bugs. If the attack is successful, the attacker will then gain full control of the host and can try to attack resources in the internal network segment. This can allow an attacker to deploy a malicious container inside the production environment.
The initial part of the attack involves enumerating the running processes in order to search for a running runC process. In a production environment, this means an attacker has access to an existing container, allowing software deployment and giving the attacker the ability to execute scripts inside a running container. Access can be obtained either through the exploitation of another vulnerability or a misconfiguration issue, or by owning a container inside a vulnerable environment.
This is followed by accessing the file descriptor using O_PATH flags:
- fd1= open("/proc/runc_pid/exe", O_PATH)
After obtaining a valid file descriptor, it opens another file descriptor using O_WRONLY flags:
- fd2 = open("/proc/self/fd/fd1", O_WRONLY )
After successfully acquiring the fd2/second file descriptor, an attacker tries to write the payload; this is done in a loop.
Triggering the vulnerability
To trigger this vulnerability, an attacker must be able to execute a binary within a container in a manner that results in spawning and terminating runC. This action allows an attacker to overwrite the runC binary.
To execute a payload, an attacker will rewrite the executed binary (eg. /bin/sh) inside a container by using a shell script #!/proc/self/exe. This will result in the execution of a modified runC binary payload.
This runC vulnerability illustrates how containers have to strike a balance between efficiency and security. However, setting up security measures early in the development pipeline can prevent greater security costs and additional work.
Recommendations and Trend Micro Solutions
To protect container machines from vulnerabilities such as CVE-2019-5736, we recommend that organizations implement the following best practices:
- Update machines regularly and consistently to minimize the chance of vulnerabilities being exploited
- Avoid running containers using root privileges, especially if it is the default configuration. To ensure that the machines are properly protected from potential attacks, only use them as application users.
- Ensure that containers are properly configured in order to maximize security. This includes proper API configuration, as well as implementing exposure to specific hosts instead of open exposure. In addition, Vendors typically have guidelines to help in setting up containers.
- Role-based access control (RBAC) security technologies can also prevent successful exploitation of CVE-2019-5736 by preventing the runC file from being overwritten
- For Linux, setting the runC file as immutable can also be used as a security measure
The following Trend Micro Deep Security Integrity Monitoring rule detects changes to any binaries in the /usr/bin and /usr/sbin directories:
- 1002770 - Unix - File Attributes Change In /usr/bin AND /usr/sbin Locations
Due to the uniqueness of this exploit , we recommend that administrators implement scheduled and/or on-demand Integrity Monitoring scans.
In addition, Deep Security File Integrity Monitoring and Application Control provide out-of-the-box visibility for this malicious activity targeting a container host. If used in lockdown mode, this application control would prevent the execution of this malicious attack.
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.
- Exposed Container Registries: A Potential Vector for Supply-Chain Attacks
- LockBit, BlackCat, and Clop Prevail as Top RAAS Groups: Ransomware in 1H 2023
- Diving Deep Into Quantum Computing: Modern Cryptography
- Uncovering Silent Threats in Azure Machine Learning Service: Part 2
- The Linux Threat Landscape Report