Bash Vulnerability in Linux, as of September 28, 2014 ----------------------------------------------------- Vulnerability in bash (shellshock) Status ------ Patches were issued for Ubuntu on Sept. 24th, 26th and 27th Apple OSX has not yet received a patch. Cygwin for Windows computers has not been patched. For Ubuntu Computers Using Bash ------------------------------- 1. Test the Bash shell with: env x='() { :;}; echo Vulnerable' bash -c "echo This is a test." 2. If it reports 'Vulnerable,' then do the following: sudo apt-get update sudo apt-get upgrade sudo apt-get clean sudo apt-get autoremove 3. Then again test the Bash shell with both commands: env x='() { :;}; echo Vulnerable' bash -c "echo This is a test." TERM='() { :;}; echo Vulnerable' bash -c "echo This is a test." Each command should generate errors that are described. The first should then report without the word 'Vulnerable' and the second command should then report without the word 'Vulnerable'. Last, this closing sentence should appear: 'This is a test.' 4. If you are patched, but want to demonstrate that you are still vulnerable, you can use this command: env X='() { (a)=>\' sh -c "echo date"; This command will return an error on a patched system, but it will still create an empty file called "echo". Description of Shellshock: -------------------------- Fedora Project community Shellshock: How does it actually work? Posted by Matthew Miller September 25, 2014 (abbreviated) env x='() { :;}; echo OOPS' bash -c : This will print “OOPS” on a vulnerable system, but exit silently if bash has been patched. And you’ve probably heard that it has something to do with environment variables. But, why is code in environment variables getting executed? Well, it’s not supposed to be — but, because of a feature which I’m tempted to call a bit too clever for its own good, there’s some room for a flaw. Bash is what you see as a terminal prompt, but it also is a scripting language, and has the ability to define functions. You do that like this: $ yayfedora() { echo "Fedora is awesome."; } and then you have a new command. Keep in mind that the “echo” here isn’t actually run yet; it’s just saved as what will happen when we run our new command. This will be important in a minute! $ yayfedora Fedora is awesome. Useful! But, let’s say, for some reason, I need to execute a new instance of bash, as a subprocess, and want to run my awesome new command under that. The statement bash -c somecommand does exactly this: runs the given command in a new shell: $ bash -c yayfedora bash: yayfedora: command not found Ooh. Sad. The child didn’t inherit the function definition. But, it does inherent the environment — a collection of key-value pairs that have been exported from the shell. (This is a whole ‘nuther concept; if you’re not familiar with this, trust me for now.) And, it turns out, bash can export functions as well. So: $ export -f yayfedora $ bash -c yayfedora Fedora is awesome. Which is all well and good — except that the mechanism by which this is accomplished is sorta dodgy. Basically, since there is no Linux/Unix magic for doing functions in environment variables, the export function actually just creates a regular environment variable containing the function definition. Then, when the second shell reads the “incoming” environment and encounters a variable with contents that look like a function, it evaluates it. In theory, this is perfectly safe, because, remember, defining a function doesn’t actually execute it. Except — and this is why we’re here — there was a bug in the code where the evaluation didn’t stop when the end of the function definition was reached. It just kepts going. That would never happen when the function stored in an environment variable is made legitimately, with export -f. But, why be legit? An attacker can just make up any old environment variable, and if it looks like a function, new bash shells will think it is! So, in our first example: env x='() { :;}; echo OOPS' bash -c : The “env” command runs a command with a given variable set. In this case, we’re setting “x” to something that looks like a function. The function is just a single “:”, which is actually a simple command which is defined as doing nothing. But then, after the semi-colon which signals the end of the function definition, there’s an echo command. That’s not supposed to be there, but there’s nothing stopping us from doing it. Then, the command given to run with this new environment is a new bash shell, again with a “do nothing :” command, after which it will exit, completely harmlessly. But — oops! When that new shell starts up and reads the environment, it gets to the “x” variable, and since it looks like a function, it evaluates it. The function definition is harmlessly loaded — and then our malicious payload is triggered too. So, if you run the above on a vulnerable system, you’ll get “OOPS” printed back at you. Or, an attacker could do a lot worse than just print things. Our update does several things. First, it fixes the flaw where the interpretation doesn’t stop at the end of the function definition (including some more sanity checks). Second, it always prefixes the magical environment variables which hold exported functions with the string BASH_FUNC_ and suffixes them with (). That means you can’t just set any arbitrary environment variable — like those passed to a web server as part of the CGI interface! — to look like a function and attack via any bash subshell that comes up later. And there’s quite a lot of other little cleanups in there too — security people at Fedora, at Red Hat, and around the world sure have been busy for the couple of days. Thanks to all of you for your hard work, and to Fedora’s awesome QA and Release Engineering teams, who sprung into action to make sure that these updates got to you quickly and safely. Shell based off "Shell" - CC-BY 3.0 by Guillaume Kurkdjian -- http://thenounproject.com/term/shell/40512/ Shell based off “Shell” – CC-BY 3.0 by Guillaume Kurkdjian — http://thenounproject.com/term/shell/40512/ Tags: Security shellshock About Matthew Miller Matthew is the current Fedora Project Leader. You can find him on the Fedora mailing lists or Freenode as "mattdm". Matthew's content on this site is made available under the Creative Commons Attribution-ShareAlike 4.0 International license — share all you like, give credit, and let others share as well. ------------------------------------------------------------------------------ From Steven J. Vaughan-Nichols 09/28/14: ---------------------------------------- The problem with the first patch, as Red Hat explained in its Shellshock FAQ, was that it only took care of the original bash flaw CVE-2014-6271. This, the true Shellshock bug, is the worst bash security hole. There were also others. Red Hat said: "Shortly after that issue went public a researcher found a similar flaw that wasn’t blocked by the first fix and this was assigned CVE-2014-7169." This bug is also a security problem, but it's not as bad as the other flaw. Later, Red Hat Product Security researcher Florian Weimer found additional problems and these were designated CVE-2014-7186 and CVE-2014-7187. Fortunately, these bugs are less serious and the latest patch takes care of these as well. As Red Hat's Huzaifa Sidhpurwala told me: "The latest version of bash fixes all the CVE issues." So, what you want to do now, if you haven't already, is check to see if you're running a vulnerable version of bash. Run the following command, created by Red Hat, from your bash shell: env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test" If you see the results below, or a variation of this in your output: $ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test" vulnerable bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)' bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable' bash: error importing function definition for `BASH_FUNC_x' test ...then you're open to Shellshock attacks. If you see: bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' bash: error importing function definition for `BASH_FUNC_x()' test ...you have a version of bash that has the basic Shellshock patch, but it can still be attacked. What you want to see is: bash: warning: x: ignoring function definition attempt bash: error importing function definition for `BASH_FUNC_x' test ...and then you'll know you have a version that's Shellshock resistant. Next, to see if your bash has been patched for the the "7169" trouble, run: cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo If you see: bash: x: line 1: syntax error near unexpected token `=' bash: x: line 1: `' bash: error importing function definition for `x' Fri Sep 26 11:49:58 GMT 2014 ...with the last line being the current date and time, then you're still vulnerable to a "7169" attack. The result you want to see is: date cat: /tmp/echo: No such file or directory