Hacker News Reader

Comment by akvadrako | Hacker News Reader

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
    / $

View on HN

No, it is not an issue, there are no suid binaries at all in the base install, so no way of changing user.

The link from the CVE says "Due to the nature of this issue, systems deployed using affected versions of the Alpine Linux container that utilize Linux PAM, or some other mechanism that uses the system shadow file as an authentication database, may accept a NULL password for the root user." - so the config would have to install PAM with suid binaries, and configure shadow passwords and not change the password. This is pretty unlikely overall.

Docker is a risk "out of the box". It requires root to run the daemon, and to use it you either need sudo or belong to the docker group which is equivalent to root access.

On their website they claim docker is "quite secure" if you "run your processes as non-privileged users inside the container", but I do not see how this would be the case given that breakouts happen all the time, AND again, it requires root to run, which gives me the opposite vibe of secure.

Docker is for convenience and it is a security risk.

Docker also has support for user namespaces which makes it so that the root inside the container is e.g. nobody outside. In general I'd say docker (with user namespaces) is quite a bit more secure than running as a normal user without containers when it comes to escaping the container/the app being breached. However this is very distinct from the fact that it basically ignores all multi user aspects of Unix when it comes to using the docker command. So while the application inside is more secure, using docker is insecure. Now in the typical deployment scenario the latter doesn't really matter since an admin deploys and the developer only creates the image locally.

If you are running as a non-privileged user inside a container, which breakouts do you think can be used to escalate privileges to the hosting machine?

All a container is, is a linux process with added security constraints. So, if you're talking about an escalation from an unprivileged process inside a container, you need a standard Linux privesc attack (nothing to do with Docker) and you also need to bypass the isolation mechanisms on that process (namespaces, capabilities, seccomp filter, SELinux/AppArmor)

It's just about possible for someone to accidentally do something like this, on "host":

  # docker run -it -p 2222:22/tcp alpine
  / # apk add openssh-server
  / # for t in ecdsa ed25519 rsa ; do ssh-keygen -t $t -C root -P '' -f /etc/ssh/ssh_host_${t}_key ; done
  / # echo PermitRootLogin yes >> /etc/ssh/sshd_config
  / # echo PermitEmptyPasswords yes >> /etc/ssh/sshd_config
  / # /usr/sbin/sshd

Then, on another machine:

  ssh -p 2222 root@host

According to the CVSS score its a huge risk. FTA:

> 9.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

(Leaving my opinion out of this.)

On every distro in the past, i’d do sudo passwd. Always worked. No idea about Alpine.

But sudo access requires you to have logged in through a user in the wheel group. That at least is not a vulnerability.

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.

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.

Alternatively, it's possible the distro added the first user account to wheel also. I believe I've seen that in the past.

How do you think that's different than the comment to which you replied?

I see, thanks. I posted hoping people would inform me about this.

Alpine comes with no suid binaries in Docker to my knowledge (it's expected you run your stuff as root inside the container unless there is a reason not to)

Just for the uninitiated:

suid binaries are binaries with a special flag set that will make it run with root privileges regardless of who started it.

sudo is an example of something that would use suid. When a user runs sudo, the binary actually runs with root privileges from the get-go, checks if the user is OK, then executes the command you specified.

However, use of sudo or other suid binaries is entirely pointless in an alpine container. There being no password also does not matter, as you are by default already running everything as root. Who cares if root can become root?

Well in theory someone could escalate their privileges to the exact same ones they already have! THAT'S TERRIBLE!

> There being no password also does not matter, as you are by default already running everything as root. Who cares if root can become root?

Best practice would have you switch to a non root user before running whatever it is inside the container. Although if you haven’t added any suid binaries by accident then there’s no way to go back.

E.g. the node alpine image adds a “node:node” user and group for the process to run as instead of root. https://github.com/nodejs/docker-node/blob/master/10/alpine/...

OK, so what’s the entire point of this article then?

Reply on news.ycombinator.com