During an assessment of the Docker platform in November 2018, two information leaks regarding the /proc/asound path were discovered in the OCI (Open Container Initiative) specification. These issues have been fixed quickly by the Docker security team using the provided suggestions.

Leak of audio device status of the host

When media is being played on the host, the

/proc/asound/card*/pcm*p/sub*/status

files may contain information regarding the status of media playback. Consider this command for a demonstration:

docker run --rm \
    ubuntu:latest bash -c \
        "sleep 5; \
        cat /proc/asound/card*/pcm*p/sub*/status | \
        grep state | \
        cut -d ' ' -f2 | \
        grep RUNNING || echo 'not running'"

When playing a media file, watching a video or executing similar actions involving sound output on the host, the above command demonstrates that a containerized process is able to gather information on this status. Therefore a process in a container is able to check whether and what kind of user activity is present on the host system. Also, this may indicate whether a container runs on a desktop system or a server as media playback rarely happens on server systems.

The scenario described above is in regard to media playback. Moreover, when examining the

/proc/asound/card*/pcm*c/sub*/status

files (pcm*c instead of pcm*p) this can also leak information regarding capturing sound, as in recording audio or making calls on the host system.

Leak of Monitor Type

Monitors can also act as sound output devices when connected using a compatible interface like DisplayPort. The listing below illustrates how the model type of the connected monitors can be read from within a container:

docker run --rm \
    ubuntu:latest bash -c \
        "cat /proc/asound/card*/eld* | \
        grep monitor_name"

monitor_name SMS24A650 # (A Samsung monitor)
monitor_name SMS24A650

This information should not be accessible from within a container as it contains specific information on the host and its environment.

These issues have been reported to the Docker maintainers were fixed by moving /proc/asound to the list of paths that are being masked to make each container manage its own versions of the affected paths. This path list is part of the OCI specification. Therefore, the fix for these issues also propagates to containerd which also uses this specification.

Lessons Learned

Containers are a construct of namespaces and cgroups in combination with some C and Go code that tie everything together. This tries to isolate the underlying system by any means necessary (which works pretty well as of today). There’s always the possibility of information leaks in case something is missed or newly introduced (either by Linux or the container managers). Theoretically, there can exist more issues of this type in the current state of container managers. Maybe some of them can be found in an automated manner? Hopefully AppArmor or similar mechanisms are in place to at least prevent writing leaked paths to prevent potential breakouts :)