Florian Weimer found that Docker is vulnerable to directory traversal flaws. If a local user were to use a command, such as "docker pull", to install a docker container, a specially crafted tarball could lead to arbitrary files on the host being overwritten. Acknowledgements: This issue was discovered by Florian Weimer of Red Hat Product Security.
docker pull requires priv, why is this a vulnerability? How can I know what to fix if there is no description?
Yes, it does require privileges. But if you give sudo privs to someone running docker, that's not the same as, say, giving them root access on the host (which they could obtain with a directory traversal flaw that allows them to overwrite /etc/shadow for instance).
If you give a person docker privs through sudo or by putting them in the docker group, you have given them root. Docker allows a user to execute any code as root, there is not protection. Even if you say there is protection via the security we have added, they can still execute docker --privileged which turns off the protections. I talk a about the lack of security in docker in this presentation. https://www.youtube.com/watch?v=zWGFqMuEHdw Now I would like to know what the bug is to fix it, but I don't believe we should be issuing CVEs for people who can run docker, in my mind this is like giving someone a CVS for allowing them to run /bin/sh as root.
(In reply to Daniel Walsh from comment #2) > docker pull requires priv, why is this a vulnerability? The command downloads tarballs and extracts them, without starting containers. I don't think there is a general expectation that this is equivalent to code execution as root on the host. > How can I know what to fix if there is no description? The reproducer looks like this (and you should have access now): lrwxrwxrwx fweimer/fweimer 0 2014-08-20 10:42 etc -> /etc -rw-rw-r-- fweimer/fweimer 31 2014-08-20 10:43 etc/passwd The Untar() function first creates the symbolic link to /etc, unlinks etc/passwd (which removes /etc/passwd), and re-creates etc/passwd (still resolves to /etc/passwd) with an Docker has already been notified and will work on a fix. In the long term, docker should probably extract the layers in a container.
I agree it is a bug, I just argue against it being a CVE. If you have the rights to install software onto a machine and the software screws up your machine, then I don't see this as a CVE.
(In reply to Daniel Walsh from comment #6) > I agree it is a bug, I just argue against it being a CVE. > > If you have the rights to install software onto a machine and the software > screws up your machine, then I don't see this as a CVE. From the CVE perspective it's a bit more complicated than that. For example we have the clear case where you have something that is supposed to be a strong security control (say a firewall) that allows packets through that should be blocked, obviously a trust boundary violation, thus a CVE. Then you have cases like servers/services that accept user supplied data and are supposed to handle it safely, but have say a buffer overflow leading to arbitrary code execution, obviously that violates a trust boundary as well. Now there is a large gray area, in this case the question is: "giving someone access to do docker stuff == root on the host" is a trust boundary violation or not? In general this is a tough one, it's generally well known that docker doesn't yet contain, but on the other hand I suspect most docker users would be shocked and horrified to find out that giving users docker means they are basically giving them root. So a major factor would be how well do we communicate this to users? E.g. Python pickle() has a huge red warning at the top of the page saying that it is unsafe, do we have anything comparable in our Docker documentation, or does upstream? For example in our docs: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Resource_Management_and_Linux_Containers_Guide/index.html Section 5.2. SECURE CONTAINERS WITH SELINUX It says doing this without SELinux is bad, but makes no mention that giving a user Docker access == root. And then in the referenced Virtualization Security Guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Virtualization_Security_Guide/index.html "Limit direct access to the system to only those users who have a need to manage the system. Consider disallowing shared root access and instead use tools such as sudo to grant privileged access to administrators based on their administrative roles." So because we haven't explicitly made it clear in our docs that access to run docker == root on the host, and neither does upstream (at least not that I can find with a quick Google search), so I'm inclined to go with: We haven't explicitly stated that sudo access to docker == root on the host, and neither has upstream, and I think it's not unreasonable for most people to assume that giving someone docker access via sudo should be safe, so in this case it looks like a trust boundary violation and thus CVE worthy.
There is a large warning at the bottom of this page: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Resource_Management_and_Linux_Containers_Guide/sec-Networking.html "By default, it listens on unix:///var/run/docker.sock to allow only local connections by the root user. It is possible to change this default to give access to everybody, but you are strongly recommended not to do it, because then it is trivial for remote attacker to gain root access to the host where Docker is running." Docker has recently released a slide deck than delves into this in more detail: http://www.slideshare.net/jpetazzo/docker-linux-containers-and-security-does-it-add-up
I would compare this to the situation that lead to simple protections against volume-mounting /. It wasn't done for security reasons per se but because the issue could cause problems even by accident. Here, I can easily imagine horrible hard-to-debug problems despite the absence of anger. More generally though, I have to throw in with Dan and David. I think we make many efforts to tell people that docker == root. It simply *is* ATM. Filing some kinds of (especially CVE) bugs isn't really productive thing at this time because they're going to (have to) be resolved with architectural changes that solves many en masse. It's much like filing bugs about each individual port < 1024 pending the architectural inclusion of a firewall. It mostly just wastes time. That said, I agree this specific issue (because of the lack of obvious container running) is a bug because the behavior is unintuitive/surprising and isn't tied to a deeper architectural choice. I don't think it necessarily cries out for a CVE, but meh. I'll file the appropriate trackers now. I definitely think our messaging is *legally* clear but if we can expand on that, we should. I'm looking at doing a blog post if not more.
The “run” command has options to drop capabilities. The meaning of those options is reduced if downloading the container can end up running arbitrary code with full capabilities, so that the restrictions on starting the container never apply. On the other hand, the image, as provided by the registry, tells Docker which user ID to use to run the image (including root). This means that by design, a system administrator needs to trust into the registry and image providers. But this information is is available with “docker inspect”, and a careful system administrator might even check it before running the container. On the third hand, once there is a malicious image we need to investigate, it would complicate the analysis if the mere step of downloading the suspicious image could be compromised. Of course, you should to do the analysis on a separate machine installed from scratch, but not being able to trust “docker inspect” or the contents of the cached tarballs in the local image cache would make the analysis rather difficult.
As the package owner, I seem to be flying blind here. When can I get access to the actual data reproducer? So I could actually look at the code and potentially create a fix. Two problems with the CVE process. 1, Hiding the actual bug from the package maintainer, so he can not react. 2. Potentially giving a false black eye to the product. (Of course this could also be a good thing, because people are being way to cavalier in their use of docker/containers, and not understanding what they are doing) I am not sure if I will ever be confident enough to say containers are secure enough to run a priv process inside an untrusted container.
(In reply to Daniel Walsh from comment #12) > As the package owner, I seem to be flying blind here. When can I get access > to the actual data reproducer? So I could actually look at the code and > potentially create a fix. Two problems with the CVE process. > > 1, Hiding the actual bug from the package maintainer, so he can not react. Normally we file against the product (e.g. rhel6/7) and add default CC's (e.g. managers) who then add the appropriate people. Our tools can support adding CC's for specific components, I think in this case it makes sense since Docker will have a lot of security related issues as things get hammered out so I've added docker+dwalsh as a default CC in our tools, so moving forwards you'll be added to the default CC for docker component in rhel7 bugs filed by our tools. -Kurt
I still look at this bug as being the equivalent of doing something bad in a rpm post install script. Not sure it requires a CVE, and should be a lesson on not installing untrusted conten on your machine. Having access to the DockerFile before installing the image would be helpful for someone to examine.
*** This bug has been marked as a duplicate of bug 1167505 ***
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-6407. Reason: This candidate is a reservation duplicate of CVE-2014-6407. Notes: All CVE users should reference CVE-2014-6407 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
Statement: This flaw was found to be a duplicate of CVE-2014-6407. Please see https://access.redhat.com/security/cve/CVE-2014-6407 for information about affected products and security errata.