How can code opened in a container execute arbitrary code outside the container?

Question

I generally work inside of docker containers both to keep my local environment clean, and to sandbox. However, when I use VSCode Remote Containers to try to open a folder in a container I am told:

Opening a folder in a Dev Container may execute arbitrary code both inside and outside the container.

The docs link, unfortunately, only talks about Workspace Trust in general and don't mention anything about the risks around containers.

What are the specific risks that I'm taking on by clicking "Trust Folder & Continue" when working inside a dev container? What attack vectors am I opening myself up to by clicking Trust here? Is there anything I can do within VSCode to mitigate the risks beyond working inside of a container (e.g., can I disable some specific feature(s))?

Answer 1

This made me very curious what may go wrong, and I have found some ways to get outside without user interaction

1. Abuse tasks.json

I thing it very cool feature may because of "runOn": "folderOpen" can lead to arbitrary code execution on the host, take a look on this example

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "start browser",
            "type": "shell",
            "command": "C:\\Progra~1\\Google\\Chrome\\Application\\chrome.exe https://stackoverflow.com",
                "runOptions": {
                "runOn": "folderOpen"
            },
            "dependsOn": ["back"]
        },
        {
            "label": "back",
            "command": "${command:remote-containers.reopenLocally}"
        }
    ]
}

You may feel running tasks inside container is safe, BUT this one doing 2 things

• on open without user interaction trying to go back to local machine
• then open browser and opens stackoverflow.com

If just had to trust this folder then tasks with option "runOn": "folderOpen" will be triggered without your interaction

Another thing is that as your host Directory and one inside docker are always synchronized it may modify own files (including tasks.json) then try to execute it

2. Abuse features/docker-outside-of-docker

If you are running dev container you may be started with additional features, one of them is called docker-outside-of-docker

    "features": {
        "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {}
    }

If Dev Container is completely remote machine maybe your host won't be touched but machine where docker is running may be damaged

Then we can create task like

        {
            "label": "list host",
            "type": "shell",
            "command": "docker run --rm -v /:/host alpine whoami && cat /etc/passwd"
        }

And execute anything on the host as root!

---

If we go to the documentation link that you talked about we can find there

Restricted Mode tries to prevent automatic code execution by disabling or limiting the operation of several VS Code features: tasks, debugging, workspace settings, and extensions.

You can clearly see that tasks are disabled along with other VS Code features that can probably lead to arbitrary code execution.

I didn't try but looking how launch.json looks like you can also see that any shell code can be executed, so even without tasks but with Docker host access can damage it, and even without this container has an access your local network and try attack your Router, Printer or other PC if they have some port open, I know it's becoming long chain but possible, take a look at Operation Triangulation: The last (hardware) mystery especially this image

So as devcontainer.json, tasks.json and launch.json are inside workspace and contain executable code they have to be trusted

Answer 2

The warning and the concept of trusted folders is what VSCode does to mitigate the risk of arbitrary code execution.

The risk precisely lies in that VSCode is running outside of the container on your machine, and it has the ability to run code.

Usually the attack vector would be build automation tasks, which are handled by tooling frameworks. And since build frameworks by definition have the power of writing to disk and execution of binaries.

Depending on the setup, it might be enough for you to open a container that has a task configuration to run certain tools upon opening, infecting the system by merely opening the project folder in VSCode with automation enabled.

To close this vector, VSCode usually will not trust the files and folders that you open, and in those scenarios it disables functions and extensions that may act as the motor behind an attack.

You can read more about the decision and thoughts behind the concept of workspace trust in this article.