2014-09-24 17:03:19 +0200, door Florian Weimer: Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes.
Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment.

The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition. For example, an environment variable setting of


will execute /bin/id when the environment is imported into the bash process. (The process is in a slightly undefined state at this point. The PATH variable may not have been set up yet, and bash could crash after executing /bin/id, but the damage has already happened at this point.)

The fact that an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation.


So far, HTTP requests to CGI scripts have been identified as the major attack vector.

A typical HTTP request looks like this:


The CGI specification maps all parts to environment variables. With Apache httpd, the magic string “() {” can appear in these places:


The user name embedded in an Authorization header could be a vector as well, but the corresponding REMOTE_USER variable is only set if the user name corresponds to a known account according to the authentication configuration, and a configuration which accepts the magic string appears somewhat unlikely.

In addition, with other CGI implementations, the request method (“GET”), path (“/path”) and query string (“query-param-name=query-param-value”) may be vectors, and it is conceivable for “query-param-value” as well, and perhaps even “query-param-name”.

The other vector is OpenSSH, either through AcceptEnv variables, TERM or SSH_ORIGINAL_COMMAND.

Other vectors involving different environment variable set by additional programs are expected.

Door Anoniem: lastig te zeggen, 'minder' vulnerable dan zij die dat wel doen. Maar als je ergens ook maar iets draait dat een shell spawnt (dhcp, een jsp pagina die iets met het fs doet, whatever) is de kans groot dat je alsnog vulnerable bent. Gewoon patchen dus.

Door Anoniem: Ik heb de patch ook net uitgerold

Deze test lijkt te niet meer kwetsbaar na de patch:
env x='() { :;}; echo kwetsbaar' bash -c "echo dit is een test"

Uit deze test blijkt dat de kwetsbaarheid nog steeds bestaat:
env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

Ik hoor dat de patch niet volledig de kwestbaarheid verhelpt. Weet iemand hoe dat zit?

Door Anoniem: Reboot is niet nodig na patchen.

Door Anoniem:
weet je dat zeker? mysql of andere services die een bash spawnen hebben hier geen last van hoeven niet herstart te worden om de nieuwe bash te gebruiken?

Door Anoniem:
Het probleem is volgens mij het meegeven van een environment variabele aan een nieuwe bash instance die bijvoorbeeld
gestart wordt voor het uitvoeren van een script. Als je bash patcht dan geldt dat (i.t.t. hoe het bij Windows gaat) meteen
al voor alle nieuwe instances, de bestaande instances blijven doordraaien op de gedelete /bin/bash file tot de laatste
daarvan exit en dan wordt die file echt verwijderd.

Het kan zijn dat een proces een permanent child proces open heeft wat bash draait, maar dat is niet zo waarschijnlijk.
De enige situatie waarin dat normaalgesproken gebeurt is een interactieve shell die door login gestart is. Die geeft dan
geen andere inbraakmogelijkheden dan een dergelijke interactieve shell altijd al heeft.

Door Anoniem: Het kan zijn dat een proces een permanent child proces open heeft wat bash draait, maar dat is niet zo waarschijnlijk.

Door ej__: Open een shell. Doe het testscript. Kwetsbaar.
Doe vanuit dezelfde shell yum update of apt-get update && apt-get upgrade.
Doe het testscript in dezelfde shell. Niet kwetsbaar.

Door ej__: Het is een uitspraak van Redhat. https://access.redhat.com/node/1200223.

Enne, misschien is het vandaag vaker en op meer systemen getest dan jij nu veronderstelt. Beetje kortzichtig, vind je ook niet?

Do I need to reboot or restart services after installing this update?

Yes, Please restart your system for using new bash package.