Closed docbill closed 9 years ago
For a quick fix, use apt-get install --only-upgrade bash
(tested on Ubuntu 14.04). However it would be great to see this included into the base images soon.
Looks like we rebuilt before the packages were fully ready or perhaps not fully propagated to mirrors. @tianon is working on this now.
Also, please see https://github.com/docker-library/official-images and #docker-library on freenode.
I mainly use the fedora, centos, and rhel based images. It looks like there is no fix yet for fedora. There is one for RHEL, but you need an active subscription. I haven't checked centos yet, but I doubt they have the fix either.
$ sudo yum update --enablerepo updates-testing bash[sudo] password for briemers: Loaded plugins: fastestmirror, langpacks, refresh-packagekit Loading mirror speeds from cached hostfile
From a docker standpoint we need a way to flag vulnerable images so they can be pulled from repositories if the maintainers don't update the images in a reasonable time frame... I'm not really sure how such a tagging would work effectively, but it would be a starting point.
A lot of people probably don't realize running containers can be re-entered with nsenter, so probably many of those who are aware of the bug, think there running containers are safe so long as they weren't launched with a command that forks shell processes...
A really quick hack one can do to fix containers that don't really need bash, is install another shell for any interactive maintenance and remove bash altogether. A "yum remove bash" command won't work, but "rm -f /bin/bash" will...
That does not of course help in the least if the docker container uses bash.
Bill
On Thu, Sep 25, 2014 at 10:54 AM, Jared Markell notifications@github.com wrote:
For a quick work-around, an easy fix is apt-get install --only-upgrade bash. However it would be great to see this included into the base images soon.
— Reply to this email directly or view it on GitHub https://github.com/docker/docker/issues/8220#issuecomment-56830473.
@docbill It also seems the patch doesn't fully fix the issue anyway.
Any update?
The patches hit the rpm mirrors yesterday. First it hit the IPv6 mirrors. By the end of the day it also hit all the IPv4 mirrors. For docker containers, you need the IPv4 mirrors so containers updated early in the day probably did not get the patched version of bash. In my opinion the patch is UGLY, but it does resolve the main security issue, which is the important thing given the alternative of not having it. I added it to all my docker images, VM's, workstation, and servers. I even used docker-enter to update the running containers that I leave running 24x7.
At first I thought I found and set of scripts broken by the update, but that was a mistake on my part. The only problem after the patch is it still allows users that can inject strings into the an environmental variable to annoy you with an error message that occurs anytime a shell is spawn. But I'll take an annoyance over a security bug any day.
Bill
On Fri, Sep 26, 2014 at 12:32 PM, Jared Markell notifications@github.com wrote:
Any update?
— Reply to this email directly or view it on GitHub https://github.com/docker/docker/issues/8220#issuecomment-56985764.
As the patches have been landing upstream we have been rebuilding the official images on the index.
@tianon
It's definitely as Michael says; we can't release fixes faster than Canonical and the Debian maintainers do. We're rebuilding images as the issues are fixed though, and most of the main base images have seen updates specifically for this issue.
@tianon Does this still need to stay open? The images have been updated.
Good point! Nope!
Thanks for getting these images updated!
Here is the link to the bug.
https://access.redhat.com/articles/1200223 https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
The following is a two simple tests. In this case I'm testing ubuntu:
docker run -e x='() { :;};echo vulnerable' --rm -i -t ubuntu bash -c 'echo this a test' docker run -e x='() { :;};echo vulnerable' --rm -i -t ubuntu sh -c 'echo this a test'
If either output the word vulnerable, they are vulnerable to the bug.
So far the only public images I found that are not susceptable are based on busybox.
Bill