Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2019-5021: Fix "DISABLE_ROOT_PASSWD" default value for build "options" files #511

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

myoung34
Copy link

@myoung34 myoung34 commented May 8, 2019

According to the write up there has been an issue with a missing -d flag in the build options files starting with Alpine 3.3 that caused the images to go out with root:: instead of root:!:

This remedies that

@tianon
Copy link
Collaborator

tianon commented May 8, 2019

I'm kind of confused here:

$ docker pull alpine:3.9
3.9: Pulling from library/alpine
Digest: sha256:28ef97b8686a0b5399129e9b763d5b7e5ff03576aa5580d6f4182a49c5fe1913
Status: Image is up to date for alpine:3.9

$ docker run --rm alpine:3.9 grep '^root:' /etc/passwd
root:x:0:0:root:/root:/bin/ash

$ docker run --rm alpine:3.9 grep '^root:' /etc/shadow
root:!::0:::::

The x in /etc/passwd means the password lives in /etc/shadow, and the ! in /etc/shadow means "password is locked".

See https://manpages.debian.org/stretch/passwd/passwd.5.en.html and https://manpages.debian.org/stretch/passwd/shadow.5.en.html. 😕

@tianon
Copy link
Collaborator

tianon commented May 8, 2019

@tianon
Copy link
Collaborator

tianon commented May 8, 2019

I suppose it makes sense to adjust that test to balk at an empty password for root specifically, but that's really not the case for alpine:3.9 so I'm confused here.

@myoung34
Copy link
Author

myoung34 commented May 8, 2019

@tianon

$ docker run -it alpine:3.2 sh -c 'cat /etc/shadow | grep root'
root:!::0:::::
$ docker run -it alpine:3.3 sh -c 'cat /etc/shadow | grep root'
root:::0:::::
$ docker run -it alpine:3.4 sh -c 'cat /etc/shadow | grep root'
root:::0:::::

@tianon
Copy link
Collaborator

tianon commented May 8, 2019

Looking at https://hub.docker.com/_/alpine, 3.2, 3.3, and 3.4 aren't actually supported anymore. 😕

@tianon
Copy link
Collaborator

tianon commented May 8, 2019

And looking at https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases, they're long-since EOL now (3.4 back on 2018-05-01).

@tianon
Copy link
Collaborator

tianon commented May 8, 2019

3.5 was EOL back in 2018-11-01.

@tianon
Copy link
Collaborator

tianon commented May 8, 2019

Updated no-hard-coded-passwords test in docker-library/official-images#5880 👍

@yosifkit
Copy link

yosifkit commented May 8, 2019

This is a duplicate of #430 and was fixed in docker-library/official-images#5516.

@ncopa
Copy link
Collaborator

ncopa commented May 9, 2019

As said, 3.3, 3.4 and 3.5 (and now also 3.6 - which is fixed) are EOL, which means that you are on your own if you use those. You can easily fix it in your Dockerfile:

# make sure root login is disabled
RUN sed -i -e 's/^root::/root:!:/' /etc/shadow

But, again, this is only a problem if:

  • you use PAM (default is off so you likely don't)
  • you run your service as non-root (docker default is to run as root). If you run your dockerized service as root, then your service already is in a state which this vulnerability would let an attacker get.

@am1ru1
Copy link

am1ru1 commented May 9, 2019

@ncopa i'm trying to ascertain if user is installing openssh whether the sshd_config will start using PAM. From what I can see, this particular patch seems to show that "UsePAM no" is commented out.
Am I reading this correctly that Openssh will enable UsePAM upon installation?

https://git.alpinelinux.org/aports/tree/main/openssh/disable-forwarding-by-default.patch

--- openssh-7.7p1/sshd_config.old	2018-04-02 00:38:28.000000000 -0500
+++ openssh-7.7p1/sshd_config	2018-07-29 03:08:16.340000000 -0500
@@ -82,9 +82,10 @@
 #UsePAM no
 
 #AllowAgentForwarding yes

@w194
Copy link

w194 commented May 9, 2019

This is a duplicate of #430 and was fixed in docker-library/official-images#5516.

what's the problem then? why isn't the PR closed yet? @yosifkit
looks like gliderlabs isn't active at all

Let's break 3495734985734985 docker builds by merging this PR....

@ncopa
Copy link
Collaborator

ncopa commented May 9, 2019

The official alpine images have moved to https://github.com/alpinelinux/docker-alpine nowdays, so this PR will not affect the official images.

This PR can be kept open for the gliderlabs images.

@ncopa
Copy link
Collaborator

ncopa commented May 9, 2019

@ncopa i'm trying to ascertain if user is installing openssh whether the sshd_config will start using PAM. From what I can see, this particular patch seems to show that "UsePAM no" is commented out.
Am I reading this correctly that Openssh will enable UsePAM upon installation?

No, the openssh-server package does not even link in linux-pam, so there are no PAM support regardless of your configuration. We do have a separate package called openssh-server-pam which is a build with PAM support.

The comment in the configuration shows the default, which means that UsePAM is disabled unless you explicitly set it to yes in your config. Even with that enabled you would still need to enable those two settings in addition:

#PermitRootLogin prohibit-password
#PermitEmptyPasswords no

@am1ru1
Copy link

am1ru1 commented May 10, 2019

As said, 3.3, 3.4 and 3.5 (and now also 3.6 - which is fixed) are EOL, which means that you are on your own if you use those. You can easily fix it in your Dockerfile:

# make sure root login is disabled
RUN sed -i -e 's/^root::/root:!:/' /etc/shadow

But, again, this is only a problem if:

  • you use PAM (default is off so you likely don't)
  • you run your service as non-root (docker default is to run as root). If you run your dockerized service as root, then your service already is in a state which this vulnerability would let an attacker get.

I am seeing a few of the CVE details stating that even the non-EOL are affected, including v3.9. Is there different test script or images being tested ? @ncopa @tianon

https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782

In builds of the Alpine Docker Image (>=3.3) the /etc/shadow file contains a blank field in place of the encrypted password (sp_pwdp in the context of the spwd struct returned by getspent.

$ for i in seq 1 9; do echo -n "date - Alpine Docker 3.$i - "; docker run -it alpine:3.$i head -n 1 /etc/shadow ; done

Thu  7 Feb 2019 16:15:43 GMT - Alpine Docker 3.1 - root:!::0:::::
Thu  7 Feb 2019 16:15:44 GMT - Alpine Docker 3.2 - root:!::0:::::
Thu  7 Feb 2019 16:15:46 GMT - Alpine Docker 3.3 - root:::0:::::
Thu  7 Feb 2019 16:15:48 GMT - Alpine Docker 3.4 - root:::0:::::
Thu  7 Feb 2019 16:15:49 GMT - Alpine Docker 3.5 - root:::0:::::
Thu  7 Feb 2019 16:15:51 GMT - Alpine Docker 3.6 - root:::0:::::
Thu  7 Feb 2019 16:15:53 GMT - Alpine Docker 3.7 - root:::0:::::
Thu  7 Feb 2019 16:15:54 GMT - Alpine Docker 3.8 - root:::0:::::
Thu  7 Feb 2019 16:15:56 GMT - Alpine Docker 3.9 - root:::0:::::

@ncopa
Copy link
Collaborator

ncopa commented May 10, 2019

Thu  7 Feb 2019 16:15:56 GMT - Alpine Docker 3.9 - root:::0:::::

That test was run 7 Feb. The images was updated March 7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants