---
title: "On CVE-2019-5021"
date: "2021-11-22"
---

A few years ago, [it was discovered that the `root` account was not locked out in Alpine's Docker images](https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782). This was not the first time that this was the case, [an actually exploitable case of this was first fixed with a hotfix in 2015](https://github.com/gliderlabs/docker-alpine/pull/109), but when the hotfix was replaced with appropriate use of `/etc/securetty`, the regression was inadvertently reintroduced for some configurations.

It should be noted that I said **some** configurations there. Although CVE-2019-5021 was issued a CVSSv2 score of 9.8, in reality I have yet to find any Alpine-based docker image that is actually vulnerable to CVE-2019-5021. Of course, this doesn't mean that Alpine shouldn't have been locking out the root user on its `minirootfs` releases: that was a mistake, which I am glad was quickly rectified.

Lately, however, there have been a few incidents involving CVE-2019-5021 involving less than honest actors in the security world. For example, a person named Donghyun Lee started [mass-filing CVEs against Alpine-based images without actually verifying if the image was vulnerable or not](https://github.com/donghyunlee00/CVE), which [Jerry Gamblin called out on Twitter last year](https://twitter.com/JGamblin/status/1338999330469011459). Other less than honest actors, have focused instead on attempting to use CVE-2019-5021 to sell their remediation solutions, implying a risk of vulnerability, where most likely none actually exists.

So, what configurations are actually vulnerable to CVE-2019-5021? Well, you must install both the `shadow` and `linux-pam` packages in the container to have any possibility of vulnerability to this issue. I have yet to find a single container which has installed these packages: think about it, Docker containers do not run multi-user, so there is no reason to configure PAM inside them. In essence, CVE-2019-5021 was a vulnerability due to the fact that the PAM configuration was not updated to align with the new Busybox configuration introduced in 2015.

And, for that matter, why is being able to escalate to `root` scary in a container? Well, if you are running a configuration without UID namespaces, `root` in the container is equivalent to `root` on the host: if the user can pivot outside the container filesystem, they can have full root access to the machine. Docker-in-docker setups with an Alpine-based container providing the Docker CLI, for example, would be easy to break out of if they were running PAM in a misconfigured way.

But in practice, nobody combines PAM with the Alpine Docker images, as there's no reason to do so. Accordingly, be wary of marketing materials discussing CVE-2019-5021, in practice your configuration was most likely never vulnerable to it.
