16 ms·

Alpine Linux Docker images have NULL for root password

359 points by alpb 7y ago

minimaxir 7y ago
Hmm? Per the Date Entry Created this was reported months ago (EDIT: I can't read), although the linked report (https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782 https://talosintelligence.com/vulnerability_reports/TALOS-20...) was posted today
- Hackbraten 7y ago
  > Disclaimer: The entry creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.
- deleted 7y ago
  [deleted]
lallysingh 7y ago
Note the conditional: "systems deployed using affected versions of the Alpine Linux container which utilize Linux PAM, or some other mechanism which uses the system shadow file as an authentication database, may accept a NULL password for the `root` user" So if you're not using a container running ssh/etc, it doesn't affect you. Serious question: what's the use of PAM in a docker image that's vulnerable here?
- scandinavian 7y ago
  For sshd you would have to set PermitEmptyPasswords to yes for it to matter, right?
  - raesene9 7y ago
    and also PermitRootLogin, AFAIK
- antod 7y ago
  I also note they could run head on /etc/shadow without sudo > docker run -it alpine:3.$i head -n 1 /etc/shadow The container process itself is running as the locally namespaced root account anyway. From my possibly incorrect interpretation... unless you are trying to build containers like VMs with multiple users and init etc, this null root password issue seems irrelevant.
akvadrako 7y ago
Is this a risk out of the box? $ docker run -it -u guest alpine / $ su su: must be suid to work properly / $ login login: must be suid to work properly / $ find / -perm /4000 -print find: /root: Permission denied find: /proc/tty/driver: Permission denied / $
- deleted 7y ago
  [deleted]
- code_duck 7y ago
  On every distro in the past, i’d do sudo passwd. Always worked. No idea about Alpine.
  - matthewbauer 7y ago
    But sudo access requires you to have logged in through a user in the wheel group. That at least is not a vulnerability.
    - code_duck 7y ago
      OK. In my experience it worked with any user account. I would install, create an account, and immediately use sudo to change the root password.
      - TheDong 7y ago
        The first user account is considered an administrator account on most distros by default, so it has sudo privileges. If you can do what you said with a non-wheel/sudo account, that would be a serious vulnerability.
        ShinTakuya 7y ago
        Alternatively, it's possible the distro added the first user account to wheel also. I believe I've seen that in the past.
s14ve 7y ago
I believe it's public on their GitHub since 5 Aug 2018. https://github.com/gliderlabs/docker-alpine/issues/430 https://github.com/gliderlabs/docker-alpine/issues/430 > 2019-03-01 - It was discovered that this issue was also reported and made public in their Github prior to our report, but was not flagged as a security issue and thus remained unresolved until it was rediscovered and reported by Cisco. https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782 https://talosintelligence.com/vulnerability_reports/TALOS-20...
- asveikau 7y ago
  > https://github.com/gliderlabs/docker-alpine/issues/430 https://github.com/gliderlabs/docker-alpine/issues/430 That issue is claimed to have been fixed, with a reference to a commit of the updated images, says issue 430 is a security issue and closed, but no link to the actual fix. Word to the wise folks: If you are fixing bugs by posting binaries, it's a good idea to include a reference to the git hash of the actual fixes you've built those binaries with.
zaroth 7y ago
Seriously, if an attacker is in a position to exploit this, hasn’t everything already failed? Or to put another way, under what condition is this actually helpful defense in depth? Nothing should be able to login locally to an Alpine container. All authentication should be public key based to begin with. What would the root password be if not null?
- detaro 7y ago
  > What would the root password be if not null? Deactivated, allowing no root login. EDIT: > Seriously, if an attacker is in a position to exploit this, hasn’t everything already failed? Not necessarily I think. Something might support PAM auth (by accident or intentionally) and it wouldn't allow anything if no/only accounts with strong passwords can be logged into, but obviously breaks once root is available for login.
hnthrow0693 7y ago
I have always been a bit surprised at the popularity of Alpine Linux for docker images. It’s awesome that the images are pretty small, but a wide variety of software has been shown to run noticeably slower on Alpine compared to other distributions, in part due to its usage of musl instead of glibc. I’d think that a few megabytes of disk isn’t as valuable as the extra cpu cycles.
- sosodev 7y ago
  I guess the question is how much slower?
  - Jonanin 7y ago
    Benchmarks here: https://www.phoronix.com/scan.php?page=article&item=docker-summer-2018&num=4 https://www.phoronix.com/scan.php?page=article&item=docker-s... For Python in particular, significantly slower.
    - nine_k 7y ago
      The Python test is indeed a large outlier! I wonder how reproducible it is, and what the reason might be.
      - aw3c2 7y ago
        That is very likely due to processor/architecture optimized precompiled Python. See e.g. https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture https://clearlinux.org/blogs/transparent-use-library-package... and https://clearlinux.org/blogs/boosting-python-profile-guided-platform-specific-optimizations https://clearlinux.org/blogs/boosting-python-profile-guided-...
  - blopker 7y ago
    I did an analysis with the official Docker Python image [0] with the --enable-optimizations flag. Although not the point of the results [1], they show a decent speed up when using Debian vs Alpine as well. [0] https://github.com/docker-library/python/issues/160 https://github.com/docker-library/python/issues/160 [1] https://gist.github.com/blopker/9fff37e67f14143d2757f9f2172c8ea0 https://gist.github.com/blopker/9fff37e67f14143d2757f9f2172c...
Drdrdrq 7y ago
What exactly is meant by null? The null / zero character, no password or 4-char string "null"?
- paulddraper 7y ago
  The NUL character is not allowed in a Linux password. Also the text of the CVE is more clear. > contain a NULL password for the `root` user It's no password.
- RKearney 7y ago
  NULL as in there is no password of any kind configured.
- adrianmonk 7y ago
  It's sloppy writing. They mean it is the empty string in /etc/shadow. Following some links from the CVE, you can find the details (from https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782 https://talosintelligence.com/vulnerability_reports/TALOS-20...): > In builds of the Alpine Docker Image (>=3.3) the /etc/shadow file contains a blank field in place of the encrypted password > ... > The net result of a blank sp_pwdp field is that the system will treat the root user as having no password, rather than a 'locked' account if a ! or is explicitly specified.* For those not super familiar with how Unix/Linux password files work, if the field is non-empty, the system will collect a password, hash it, and compare for a match. If the field is empty, the system will just skip prompting for a password and log you in after entering a username. Arguably, this is crappy design and a better design for /etc/shadow would be to require some kind of explicit, very obvious value like "NO-PASSWORD-REQUIRED".
  - Drdrdrq 7y ago
    Thanks!
  - jlgaddis 7y ago
    > Arguably, this is crappy design and a better design for /etc/shadow would be to require some kind of explicit, very obvious value like "NO-PASSWORD-REQUIRED". I think pretty much all Linux distributions use PAM nowadays (although I'm sure there are exceptions). From pam_unix.so(8): > The default action of this module is to not permit the user access to a service if their official password is blank. Unfortunately, many distributions pass the "nullok" option to the pam_unix.so module, overriding this default behavior. Removing any instances of "nullok" from any files in /etc/pam.d/ is highly recommended -- unless you explicitly want this behavior (which could be a reasonable choice, in some specific use cases).
nine_k 7y ago
> Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the `root` user. This vulnerability appears to be the result of a regression introduced in December of 2015. Emphasis mine. If this tells us something is that how inconsequential is that. A lot of software already runs with uid 0 inside a container. So, if you got an RCE in that software, you've got a container root anyway. Containers normally do not expose anything else but the target daemon to the network, so cracking in through a non-privileged daemon is unlikely. Container's root does not map to host's root, so any intrusion is most likely limited to the container if detected soon enough (though it's far from being bullet-proof).
- cpuguy83 7y ago
  Container's root most certainly does map to host root unless you've enabled user namespaces (which is painful). However, root in a container does have many privileges dropped and seccomp policies applied (assuming you haven't turned seccomp off via k8s).
- shakna 7y ago
  > The likelihood of exploitation of this vulnerability is environment-dependent, as successful exploitation requires that an exposed service or application utilise Linux PAM, or some other mechanism which uses the system shadow file as an authentication database. It depends how you have things set up, and what the container is actually doing, and what it's linked to. So it may not be as critical as root on the server, but it may also allow some damage that is more than irritating to happen. I would call it serious, but not critical.
paulddraper 7y ago
I highly recommend using user namespaces for Docker. [1] It means the host is protected from privilege escalation in the container. [1] https://docs.docker.com/engine/security/userns-remap/ https://docs.docker.com/engine/security/userns-remap/
asdfe 7y ago
This is not the official Alpine image, it is Glider Labs one.
- silverwind 7y ago
  Yeah, official alpine one looks fine $ docker run -it alpine head -1 /etc/shadow root:!::0:::::
  - LukeShu 7y ago
    Going through alpine:3.1 to alpine:3.9, then alpine:edge, I see that the following versions have the problem: 3.3, 3.4, 3.5, and 3.8.
    - deathanatos 7y ago
      3.8 looks fine? » docker run --rm -ti alpine:3.8 sh -c 'cat /etc/shadow | grep root' root:!::0::::: The others you mention though, I agree, they look less than fine. Also, has anyone reported this to the official Alpine repository? (since the Talos disclosure seems to be confused; it says official but has URLs to the Glider Labs version?) Edit: Ah, so here's the relevant GitHub issue for official Alpine Linux docker: https://github.com/docker-library/official-images/pull/5516 https://github.com/docker-library/official-images/pull/5516 <=3.5 is no longer supported. Everything newer is patched.
      - kamane 7y ago
        What should be done to prevent NULL password then? Like just setting a custom strong password for root user in alpine container Dockerfile ? If yes, could you share the recipe how to correctly do it?
        captn3m0 7y ago
        Update your base images
      - 7y ago
shakna 7y ago
> Eight days after this vulnerability was initially fixed, a commit was pushed which removed this 'disable root by default' flag from the 'edge' build properties file, reintroducing this issue to subsequent builds. That... Did not take long. From fix, to regression on a fairly serious security issue (though perhaps not critical, depending how the container infrastructure is set up). > Unfortunately, later that same year, a commit was pushed to simplify the regression tests. This lead to logic that may have caught this regression being simplified, causing these tests to be incorrectly 'satisfied' if the root password was once again removed. Testing is hard, and ensuring you meet the requirements but keeping it readable can be harder.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
foxhop 7y ago
I thought this was intentional when I stumbled on it a month ago.
indigodaddy 7y ago
If your box gets rooted because of this then you already had glaring security issues.
justanegg 7y ago
you know what alpine linux is for right?

359 points by alpb 7y ago

Hmm? Per the Date Entry Created this was reported months ago (EDIT: I can't read), although the linked report (https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782 https://talosintelligence.com/vulnerability_reports/TALOS-20...) was posted today

Hackbraten 7y ago
> Disclaimer: The entry creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.
deleted 7y ago
[deleted]

lallysingh 7y ago

Note the conditional: "systems deployed using affected versions of the Alpine Linux container which utilize Linux PAM, or some other mechanism which uses the system shadow file as an authentication database, may accept a NULL password for the `root` user" So if you're not using a container running ssh/etc, it doesn't affect you. Serious question: what's the use of PAM in a docker image that's vulnerable here?

scandinavian 7y ago
For sshd you would have to set PermitEmptyPasswords to yes for it to matter, right?
- raesene9 7y ago
  and also PermitRootLogin, AFAIK
antod 7y ago
I also note they could run head on /etc/shadow without sudo > docker run -it alpine:3.$i head -n 1 /etc/shadow The container process itself is running as the locally namespaced root account anyway. From my possibly incorrect interpretation... unless you are trying to build containers like VMs with multiple users and init etc, this null root password issue seems irrelevant.

akvadrako 7y ago

Is this a risk out of the box? $ docker run -it -u guest alpine / $ su su: must be suid to work properly / $ login login: must be suid to work properly / $ find / -perm /4000 -print find: /root: Permission denied find: /proc/tty/driver: Permission denied / $

deleted 7y ago
[deleted]
code_duck 7y ago
On every distro in the past, i’d do sudo passwd. Always worked. No idea about Alpine.
- matthewbauer 7y ago
  But sudo access requires you to have logged in through a user in the wheel group. That at least is not a vulnerability.
  - code_duck 7y ago
    OK. In my experience it worked with any user account. I would install, create an account, and immediately use sudo to change the root password.
    - TheDong 7y ago
      The first user account is considered an administrator account on most distros by default, so it has sudo privileges. If you can do what you said with a non-wheel/sudo account, that would be a serious vulnerability.
      - ShinTakuya 7y ago
        Alternatively, it's possible the distro added the first user account to wheel also. I believe I've seen that in the past.

s14ve 7y ago

I believe it's public on their GitHub since 5 Aug 2018. https://github.com/gliderlabs/docker-alpine/issues/430 https://github.com/gliderlabs/docker-alpine/issues/430 > 2019-03-01 - It was discovered that this issue was also reported and made public in their Github prior to our report, but was not flagged as a security issue and thus remained unresolved until it was rediscovered and reported by Cisco. https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782 https://talosintelligence.com/vulnerability_reports/TALOS-20...

asveikau 7y ago
> https://github.com/gliderlabs/docker-alpine/issues/430 https://github.com/gliderlabs/docker-alpine/issues/430 That issue is claimed to have been fixed, with a reference to a commit of the updated images, says issue 430 is a security issue and closed, but no link to the actual fix. Word to the wise folks: If you are fixing bugs by posting binaries, it's a good idea to include a reference to the git hash of the actual fixes you've built those binaries with.

zaroth 7y ago

Seriously, if an attacker is in a position to exploit this, hasn’t everything already failed? Or to put another way, under what condition is this actually helpful defense in depth? Nothing should be able to login locally to an Alpine container. All authentication should be public key based to begin with. What would the root password be if not null?

detaro 7y ago
> What would the root password be if not null? Deactivated, allowing no root login. EDIT: > Seriously, if an attacker is in a position to exploit this, hasn’t everything already failed? Not necessarily I think. Something might support PAM auth (by accident or intentionally) and it wouldn't allow anything if no/only accounts with strong passwords can be logged into, but obviously breaks once root is available for login.

hnthrow0693 7y ago

I have always been a bit surprised at the popularity of Alpine Linux for docker images. It’s awesome that the images are pretty small, but a wide variety of software has been shown to run noticeably slower on Alpine compared to other distributions, in part due to its usage of musl instead of glibc. I’d think that a few megabytes of disk isn’t as valuable as the extra cpu cycles.

sosodev 7y ago
I guess the question is how much slower?
- Jonanin 7y ago
  Benchmarks here: https://www.phoronix.com/scan.php?page=article&item=docker-summer-2018&num=4 https://www.phoronix.com/scan.php?page=article&item=docker-s... For Python in particular, significantly slower.
  - nine_k 7y ago
    The Python test is indeed a large outlier! I wonder how reproducible it is, and what the reason might be.
    - aw3c2 7y ago
      That is very likely due to processor/architecture optimized precompiled Python. See e.g. https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture https://clearlinux.org/blogs/transparent-use-library-package... and https://clearlinux.org/blogs/boosting-python-profile-guided-platform-specific-optimizations https://clearlinux.org/blogs/boosting-python-profile-guided-...
- blopker 7y ago
  I did an analysis with the official Docker Python image [0] with the --enable-optimizations flag. Although not the point of the results [1], they show a decent speed up when using Debian vs Alpine as well. [0] https://github.com/docker-library/python/issues/160 https://github.com/docker-library/python/issues/160 [1] https://gist.github.com/blopker/9fff37e67f14143d2757f9f2172c8ea0 https://gist.github.com/blopker/9fff37e67f14143d2757f9f2172c...

Drdrdrq 7y ago

What exactly is meant by null? The null / zero character, no password or 4-char string "null"?

paulddraper 7y ago
The NUL character is not allowed in a Linux password. Also the text of the CVE is more clear. > contain a NULL password for the `root` user It's no password.
RKearney 7y ago
NULL as in there is no password of any kind configured.
adrianmonk 7y ago
It's sloppy writing. They mean it is the empty string in /etc/shadow. Following some links from the CVE, you can find the details (from https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782 https://talosintelligence.com/vulnerability_reports/TALOS-20...): > In builds of the Alpine Docker Image (>=3.3) the /etc/shadow file contains a blank field in place of the encrypted password > ... > The net result of a blank sp_pwdp field is that the system will treat the root user as having no password, rather than a 'locked' account if a ! or is explicitly specified.* For those not super familiar with how Unix/Linux password files work, if the field is non-empty, the system will collect a password, hash it, and compare for a match. If the field is empty, the system will just skip prompting for a password and log you in after entering a username. Arguably, this is crappy design and a better design for /etc/shadow would be to require some kind of explicit, very obvious value like "NO-PASSWORD-REQUIRED".
- Drdrdrq 7y ago
  Thanks!
- jlgaddis 7y ago
  > Arguably, this is crappy design and a better design for /etc/shadow would be to require some kind of explicit, very obvious value like "NO-PASSWORD-REQUIRED". I think pretty much all Linux distributions use PAM nowadays (although I'm sure there are exceptions). From pam_unix.so(8): > The default action of this module is to not permit the user access to a service if their official password is blank. Unfortunately, many distributions pass the "nullok" option to the pam_unix.so module, overriding this default behavior. Removing any instances of "nullok" from any files in /etc/pam.d/ is highly recommended -- unless you explicitly want this behavior (which could be a reasonable choice, in some specific use cases).

nine_k 7y ago

> Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the `root` user. This vulnerability appears to be the result of a regression introduced in December of 2015. Emphasis mine. If this tells us something is that how inconsequential is that. A lot of software already runs with uid 0 inside a container. So, if you got an RCE in that software, you've got a container root anyway. Containers normally do not expose anything else but the target daemon to the network, so cracking in through a non-privileged daemon is unlikely. Container's root does not map to host's root, so any intrusion is most likely limited to the container if detected soon enough (though it's far from being bullet-proof).

cpuguy83 7y ago
Container's root most certainly does map to host root unless you've enabled user namespaces (which is painful). However, root in a container does have many privileges dropped and seccomp policies applied (assuming you haven't turned seccomp off via k8s).
shakna 7y ago
> The likelihood of exploitation of this vulnerability is environment-dependent, as successful exploitation requires that an exposed service or application utilise Linux PAM, or some other mechanism which uses the system shadow file as an authentication database. It depends how you have things set up, and what the container is actually doing, and what it's linked to. So it may not be as critical as root on the server, but it may also allow some damage that is more than irritating to happen. I would call it serious, but not critical.

paulddraper 7y ago

I highly recommend using user namespaces for Docker. [1] It means the host is protected from privilege escalation in the container. [1] https://docs.docker.com/engine/security/userns-remap/ https://docs.docker.com/engine/security/userns-remap/

asdfe 7y ago

This is not the official Alpine image, it is Glider Labs one.

silverwind 7y ago
Yeah, official alpine one looks fine $ docker run -it alpine head -1 /etc/shadow root:!::0:::::
- LukeShu 7y ago
  Going through alpine:3.1 to alpine:3.9, then alpine:edge, I see that the following versions have the problem: 3.3, 3.4, 3.5, and 3.8.
  - deathanatos 7y ago
    3.8 looks fine? » docker run --rm -ti alpine:3.8 sh -c 'cat /etc/shadow | grep root' root:!::0::::: The others you mention though, I agree, they look less than fine. Also, has anyone reported this to the official Alpine repository? (since the Talos disclosure seems to be confused; it says official but has URLs to the Glider Labs version?) Edit: Ah, so here's the relevant GitHub issue for official Alpine Linux docker: https://github.com/docker-library/official-images/pull/5516 https://github.com/docker-library/official-images/pull/5516 <=3.5 is no longer supported. Everything newer is patched.
    - kamane 7y ago
      What should be done to prevent NULL password then? Like just setting a custom strong password for root user in alpine container Dockerfile ? If yes, could you share the recipe how to correctly do it?
      - captn3m0 7y ago
        Update your base images
    - 7y ago

shakna 7y ago

> Eight days after this vulnerability was initially fixed, a commit was pushed which removed this 'disable root by default' flag from the 'edge' build properties file, reintroducing this issue to subsequent builds. That... Did not take long. From fix, to regression on a fairly serious security issue (though perhaps not critical, depending how the container infrastructure is set up). > Unfortunately, later that same year, a commit was pushed to simplify the regression tests. This lead to logic that may have caught this regression being simplified, causing these tests to be incorrectly 'satisfied' if the root password was once again removed. Testing is hard, and ensuring you meet the requirements but keeping it readable can be harder.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

foxhop 7y ago

I thought this was intentional when I stumbled on it a month ago.

indigodaddy 7y ago

If your box gets rooted because of this then you already had glaring security issues.

justanegg 7y ago

you know what alpine linux is for right?