17 lines
2.8 KiB
Markdown
17 lines
2.8 KiB
Markdown
|
---
|
||
|
|
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.
|