I’m guessing most people have heard about the security issue that was discovered in bash earlier in the week, which has been nicknamed Shellshock. Most of the details are covered elsewhere, so I thought I would post a little about the handling of the issue in Arch.
I am the Arch Linux contact on the restricted oss-securty mailing list. On Monday (at least in my timezone…), there was a message saying that a significant security issue in bash would be announced on Wednesday. I let the Arch bash maintainer and he got some details.
This bug was CVE-2014-6271. You can test if you are vulnerable by running
x="() { :; }; echo x" bash -c :
If your terminal prints “x“, then you are vulnerable. This is actually more simple to understand than it appears… First we define a function x() which just runs “:“, which does nothing. After the function is a semicolon, followed by a simple echo statement – this is a bit strange, but there is nothing stopping us from doing that. Then this whole function/echo bit is exported as an environmental variable to the bash shell call. When bash loads, it notices a function in the environment and evaluates it. But we have “hidden” the echo statement in that environmental variable and it gets evaluated too… Oops!
The announcement of CVE-2014-6271 was made at 2014-09-24 14:00 UTC. Two minutes and five seconds later, the fix was committed to the Arch Linux [testing] repository, where it was tested for a solid 25 minutes before releasing into our main repositories.
About seven hours later, it was noticed that the fix was incomplete. The simplified version of this breakage is
X='() { function a a>\' bash -c echo
This creates a file named “echo” in the directory where it was run. To track the incomplete fix, CVE-2014-7169 was assigned. A patch was posted by the upstream bash developer to fix this issue on the Wednesday, but not released on the bash ftp site for over 24 hours.
With a second issue discovered so quickly, it is important not to take an overly reactive approach to updating as you run the risk of introducing even worse issues (despite repeated bug reports and panic in the forum and IRC channels). While waiting for the dust to settle, there was another patch posted by Florian Weimer (from Red Hat). This is not a direct fix for any vulnerability (however see below), but rather a hardening patch that attempts to limit potential issues importing functions from the environment. During this time there was also patches posted that disabled importing functions from the environment all together, but this is probably an over reaction.
About 36 hours after the first bug fix, packages were released for Arch Linux that fixed the second CVE and included the hardening patch (which upstream appears to be adopting with minor changes). There were also two other more minor issues found during all of this that were fixed as well – CVE-2014-7186 and CVE-2014-7187.
And that is the end of the story… Even the mystery CVE-2014-6277 is apparently covered by the unofficial hardening patch that has been applied. You can test you bash install using the bashcheck script. On Arch Linux, make sure you have bash>=4.3.026-1 installed.
And because this has been a fun week, upgrade NSS too!
Thanks Allan for this nice summary. Have a next nice week. 🙂
Greetings
I just wanted to say thanks, too. Glad to be an Arch user.
pacman -S bash installs bash-4.3.024-2 which appears to still be vulnerable to CVE-2014-7186; as you can see when you run this test:
bash -c ‘true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"
BTW, the output I get is:
bash: warning: testbug: ignoring function definition attempt
bash: error importing function definition for `testbug’
Segmentation fault
CVE-2014-7186 vulnerable, redir_stack
bash-4.3.027-1 is in [core] and bash-4.3.028-1 is in [testing]. Your mirror is bad.
Sorry, my mistake, after a fully system upgrade (-Syu), bash was upgraded to 4.3.27(1)-release which appears to no longer be vulnerable.
Well the fix was fast!
But this bring a question.
in Arch is a program packaged by arch have a script that invoke #/bin/sh but use bashisms or full bash need to be reported in Arch as a bug and uptream to correct to #/bin/bash or is ok to keep as sh+bashisms.
I want know if need to report or not.
You knoe “Not ignore bug, report them” as in the forum say.
A script call /bin/sh and having bashisms is a bug. Report it.