5 ms·

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

• deleted 8y ago
  [deleted]
• code_duck 8y ago
  On every distro in the past, i’d do sudo passwd. Always worked. No idea about Alpine.
  • matthewbauer 8y 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 8y 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 8y 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 8y ago
          Alternatively, it's possible the distro added the first user account to wheel also. I believe I've seen that in the past.
          • Godel_unicode 8y ago
            How do you think that's different than the comment to which you replied?
        • code_duck 8y ago
          I see, thanks. I posted hoping people would inform me about this.
  • zaarn 8y ago
    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)
    • arghwhat 8y ago
      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?
      • zaarn 8y ago
        Well in theory someone could escalate their privileges to the exact same ones they already have! THAT'S TERRIBLE!
      • javagram 8y ago
        > 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/Dockerfile https://github.com/nodejs/docker-node/blob/master/10/alpine/...
      • code_duck 8y ago
        OK, so what’s the entire point of this article then?
• justincormack 8y ago
  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.
• deleted 8y ago
  [deleted]
• johnisgood 8y ago
  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.
  • spacenick88 8y ago
    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.
  • raesene9 8y ago
    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)
  • deleted 8y ago
    [deleted]
• bloak 8y ago
  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
• Fnoord 8y ago
  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.)