How does this affect the Fedora Docker containers? Here is a great article on understanding how Shellshock works. As far as how it affects Fedora Docker containers, there are two sets of images that we need to be aware of. The first is the Fedora base image. The Fedora base image comes with bash because it is pulling in the @core package group as part of the image build process. We can check this out by pulling down the Fedora base image and having a look inside.
$ sudo docker run -it fedora:20 /bin/bash # rpm -qa | grep -i bash bash-4.2.48-2.fc20.x86_64
Since we are in here, why not check for the vulnerability? Per the article linked to above, we can issue the following command to determine if we are vulnerable or not.
[root@daea845b93d1 /]# env x='() { :;}; echo OOPS' bash -c :
[root@daea845b93d1 /]#
And we can see with a silent exit, we are not vulnerable. Secondly, we need to be aware of the Fedora layered images on the Docker hub. So, does this mean that all the Fedora images hosted on the Docker hub are patched? There’s an important order of operations here that needs to be noted. The Fedora images are built off of the base image. So, there are a couple of scenarios that we need to be aware of:
- The base image has been updated, and we build a new layered image off of the Fedora base image to host on the Docker hub. In this case, everything is up to date.
- The base image bas been updated, but the images on Docker hub were already there and built off of a base image that had the vulnerability.
For the second scenario, there’s an easy fix for that as well. All that is required is to go into the Docker hub dashboard and trigger a build. Now, this works because the Fedora Docker hub account is linked to the Fedora Dockerfiles github repo. The first command in each Dockerfile on the repo is a:
RUN yum -y update && yum clean all
So, when the build is triggered, it parses the Dockerfile, updates the image and we are patched because the yum update pulls the latest Bash package. We work hard to keep the Fedora base image updated as well as the layered images on the Docker hub. To confirm that the fix has been applied, pick an image from list on the Docker hub and give it a test.
$ sudo docker run -it fedora/apache bash
Unable to find image 'fedora/apache' locally
Pulling repository fedora/apache
2e11d8fd18b3: Download complete
<snip>
f0b140ef8cdd: Download complete
b05601b61180: Download complete
[root@bf33bf0606c5 /]# env x='() { :;}; echo OOPS' bash -c :
[root@bf33bf0606c5 /]#
And we have a silent exit here. There were actually 2 vulnerabilities discovered. One was of arbitrary code execution and the other was file creation. Both have been patched in the latest Docker base image and layered images.
Joe Pesco
The article cited explains well, and correctly, the the use of the exported function feature of GNU Bash. Exported functions are good a feature. I put a bunch of hours in this week toying with my use of one such function that I export, because it is a utility that keeps state information persistent between instances of the shell. While debugging backing in, and out of shell instances is disorienting. It’s nice to have you command line prompt land in the same place with the same resources at you fingertips while working. I guess I’m like many others and sometimes leave vim open in the background to stop me from exiting all the way back to the GUI. I’m also like everyone else, and get mad when features don’t work as advertised.
My purpose here is to say exported functions are much less wear, and tear on the flip-flops than doing the other thing I’m fond of, a sheband with a login shell: `#!/bin/bash -l’. I’m fond of this construct, but don’t use it much, because at worst you could have a real hinky race condition.
Perhaps what I’ll do is write a short article for Planet Fedora illustrating what I’ve said. Thank you for you time.