Thursday, September 25, 2014

Bashing bash one more time: updated universal 4.3.30 covering all known bash flaws

FINAL UPDATE: 4.3.30 is now available. There are no new tests, and it is not clear the flaws it fixes are exploitable with the other changes, but it is available for those that wish it. Assuming no other vulnerabilities are found in the near future, this should be the last patch.

UPDATE THE THIRD: To clarify some questions, 4.3.28 is not vulnerable to CVE-2014-6277 and -6278, as well as all the other reported vulnerabilities. See Michal Zalewski's post on the subject.

UPDATE THE SECOND: It's a bug bash! Updated to 4.3.28 below with more fixes for two more internal vulnerabilities (CVE-2014-7186 and -7187). Hopefully this should be the last one for awhile. Just overlay it over your old copy of 4.3.2x.

UPDATE: bash just keeps on giving. Updated to 4.3.27 below with more steps to repair this vulnerability. Just overlay it over your old copy of 4.3.26.

See the previous entry, but in short, bash has been shown to have a pretty nasty little vulnerability that causes it to inadvertently execute shell commands in the environment you pass it. This attack does work on Power Macs because most shell commands are cross-platform, and appears to exist on all versions of OS X.

The solution is easy: build a new bash from the newly patched source code. As a service to you, I have done so, and compiled it for PowerPC and Intel so it will also work for users on 10.6 who are not receiving updates either. See above The version earlier today had a preliminary version of the patch which does not fix a second variant vulnerability. This version does. If you used one of the "build from source" tricks that were circulating earlier today (MacRumors, etc.), your version does NOT have this second issue patched. Either wait for the public source trees to update and rebuild it (likely early tomorrow), or use this one.

The bash these steps will install works on 10.4 all the way to 10.9 on 32-bit Intel, 64-bit Intel and PowerPC. It requires no other dependencies. The idea is to replace your system bash -- yes, you can use Homebrew, Tigerbrew, MacPorts, etc., to get an updated copy, but your built-in bash is still vulnerable unless you replace it. This is designed to accomplish that. WARNING AGAIN: If you are not comfortable with the Terminal, get someone to help you!

  1. In a Terminal.app window, verify that you have a vulnerable system so that you can see what that looks like (the command is all one line):

    env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

    It should print

    vulnerable
    this is a test

  2. Check the second vulnerability. This creates a file called echo with the date in it, if your system is vulnerable:

    env X='() { (a)=>\' sh -c "echo date"; cat echo

    It should print something like (the messages and of course the time will vary):

    bash: X: line 1: syntax error near unexpected token `='
    bash: X: line 1: `'
    bash: error importing function definition for `X'
    Thu Sep 25 22:12:49 PDT 2014

    (Delete the file it makes before you continue! rm echo)

  3. Check the third vulnerability.

    env foo='() { echo not patched; }' bash -c foo

    It should print

    not patched

  4. NEW: Check the fourth vulnerability.

    bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "vulnerable"

    It should print (the exact number of lines may vary):

    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 1 delimited by end-of-file (wanted `EOF')
    Bus error
    vulnerable

  5. NEW: Check the fifth vulnerability.

    bash -c '( for x in {1..200} ; do echo "for x$x in ; do :" ; done ; for x in {1..200} ; do echo done ; done )' | bash || echo "vulnerable"

    It should print (the exact number may vary):

    bash: line 129: syntax error near `x129'
    bash: line 129: `for x129 in ; do :'
    vulnerable

  6. This has now been patched to 4.3.30. This has now been patched to 4.3.28. This has now been patched to 4.3.27. Download the patched bash 4.3.26. Put it in your home directory. If necessary, double-click to decompress it so that you have a file in your home directory called bash-4.3.30-10.4u.

  7. Close all terminal windows and programs just to make sure you won't stomp on bash while a program is trying to call it. Start Terminal and have exactly one window open.

  8. In that terminal window:

    • exec tcsh
    • chmod +x bash-4.3.30-10.4u

      If you replaced /bin/bash (and/or /bin/sh) with any earlier version of these patched bashes, DO NOT DO THE NEXT TWO COMMANDS. If you have never replaced them, go ahead; these will put the old ones in a safe place, just in case.

    • sudo mv /bin/bash /bin/bash_old (enter your password)
    • sudo mv /bin/sh /bin/sh_old (enter your password if needed)

      Everybody does these:

    • sudo cp bash-4.3.30-10.4u /bin/bash (enter your password if needed)
    • sudo cp bash-4.3.30-10.4u /bin/sh (enter your password if needed)

  9. Test it stuck by trying the statements again:

    env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

    It should print

    this is a test

    Now, try the second one:

    env X='() { (a)=>\' sh -c "echo date"; cat echo

    It should print

    date
    cat: echo: No such file or directory

    If this test appears to fail, make sure that you delete the file echo (rm echo) first, and test it again.

    Now, try the third one:

    env foo='() { echo not patched; }' bash -c foo

    It should print

    bash: foo: command not found

    Now, try the fourth one:

    bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "vulnerable"

    It should print (there should be exactly 14 lines, one for each <<EOF):

    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')
    bash: line 1: warning: here-document at line 0 delimited by end-of-file (wanted `EOF')

    Now, try the fifth one:

    bash -c '( for x in {1..200} ; do echo "for x$x in ; do :" ; done ; for x in {1..200} ; do echo done ; done )' | bash || echo "vulnerable"

    Nothing will appear. However, if you want a positive test, do the following:

    bash -c '( for x in {1..200} ; do echo "for x$x in ; do :" ; done ; for x in {1..200} ; do echo done ; done )' | bash && echo "not vulnerable"

    It should print:

    not vulnerable

  10. Restart your Mac as a paranoia to make sure everything is using the new copy of bash.

  11. Bask in the glow. Then, find a shell that doesn't suck.

102 comments:

  1. Thank you! This is exactly what I was looking for to protect my old but treasured PPC Macs.

    ReplyDelete
  2. Thanks for posting this ClassicHasClass. I have two Tiger servers where I've tried to follow patch methods outlined elsewhere and each crashes upon executing the xcodebuild command. I hope to try your method soon once I build up the confidence to hit the command line again. :-)

    ReplyDelete
  3. Thanks for posting this. Patched applied to a Mac OS X 10.5.8 Server on a PowerMac G5.

    ReplyDelete
  4. verdant

    Fantastic - thanks so much for your public spirit in providing this universal patch for PPC/Intel and 10.4 thru to 10.9 so quickly! I have both PPC and Intel OS X 10.4 thru to 10.9 systems that are now protectable agains both bash vulnerabilities.

    ReplyDelete
  5. I couldn't get this to work on my G4 MDD running Mac OSX 10.5.8...

    ReplyDelete
  6. works like a charm on a G5 dualie under 10.5.8.

    Thanks much (also for 104fx!)

    ReplyDelete
  7. This is great (yay for PPC binaries!) but appears not to cover the bash vulnerability in CVE-2014-6277 and the fix included in bash 4.3.27, see here:

    http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html

    You can test if you're patched against the bug with:
    foo='() { echo not patched; }' bash -c foo

    Any chance of a recompile? (Though I'm thankful anyone is compiling binaries for older Macs at all!)

    ReplyDelete
    Replies
    1. I just saw that -- sorry, I was out of town most of yesterday and missed the fireworks on the mailing list. 4.3.27 is now up. See updated blog post.

      Delete
  8. I just tried the steps to overwrite v. 4.3.26, which I installed successfully on Saturday, with v. 4.3.26. I followed them exactly, including skipping the two steps to move the original bash and rename it. But it failed.

    In the end, the tests do not result in the correct response in Terminal, not the response at the top of this page for a bad bash nor the response at bottom for a good bash. For example, the first test merely results in the response of: this is a test. It doesn't say "vulnerable," but neither does it give the proper response for not being vulnerable.

    So, now what do I do? Something is wrong and has to be fixed, or I am in worse shape then when I started. I have to now think I have no protection.

    I'm using OS X 10.5.8 on a PPC G4 tower.

    Help.

    ReplyDelete
    Replies
    1. It would be helpful to post what you actually saw.

      Delete
    2. Well, I did post what I actually saw on the first test after doing the Terminal commands:

      this is a test

      That's all. That's the wrong response, so it failed. I just now did the next two tests, and here is the Terminal window on them (I changed the computer name to XXXXX):

      Last login: Mon Sep 29 11:37:31 on ttys000
      Unknown:~ XXXXX$ env X='() { (a)=>\' sh -c "echo date"; cat echo
      date
      cat: echo: No such file or directory
      Unknown:~ XXXXX$ env foo='() { echo not patched; }' bash -c foo
      bash: foo: command not found
      Unknown:~ XXXXX$

      Some additional info I just learned. I did an Get Info on the downloaded v. 4.3.27, and then on the bash now in the proper location after doing the Terminal stall commands. They have different creation dates.

      The one that is installed now has a creation date of Saturday, Sept. 27, 2014. It says it was modified today at 11:24 a.m. (maybe that is when I did the install). It does not give a version number. But the version downloaded this morning has a created date of today, and created and modified at 10:15 a.m.

      In Get Info, the extension name of the one now installed in the correct spot is "bash." The extension name of the one downloaded this morning is "bash-4.3.27-10.4u."

      Delete
    3. Please give me the results of

      bash --version
      sh --version

      (Note: two dashes.) They should say exactly the same thing, i.e.,

      GNU bash, version 4.3.27(3)-release (powerpc-apple-darwin8.11.0)

      Delete
    4. Both say v. 4.3.27. Here is the Terminal window on them:


      Last login: Mon Sep 29 12:13:15 on ttys000
      Unknown:~ XXXXX$ bash --version
      GNU bash, version 4.3.27(3)-release (powerpc-apple-darwin8.11.0)
      Copyright (C) 2013 Free Software Foundation, Inc.
      License GPLv3+: GNU GPL version 3 or later

      This is free software; you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
      Unknown:~ XXXXX$ sh --version
      GNU bash, version 4.3.27(3)-release (powerpc-apple-darwin8.11.0)
      Copyright (C) 2013 Free Software Foundation, Inc.
      License GPLv3+: GNU GPL version 3 or later

      This is free software; you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
      Unknown:~ XXXXX$

      Delete
    5. This is my error. I need to update the output messages. Your version is correctly installed. You don't need to do anything else.

      Delete
    6. OK, then all is good -- and I'm glad I could help. And I thank you for all your efforts.

      Let me ask: whiIe I'm good now, I would rather have the right thing working right, including those messages. So, when you update it, I guess I could just then overwrite with your new version? And then I should get the correct messages.

      Delete
    7. Yes, you can just overwrite it directly. That's exactly how I'm installing it on my systems.

      Delete
    8. OK, and when you put that up, will it be v. 4.3.28, or something else, or maybe the same version number but you will not it is updated from the morning post? Maybe v. 4.3.27a.

      Thanks for all your efforts. You have saved us all. :)

      Delete
    9. The version number will be whatever it's set to upstream. I don't make any modifications to the source code. Generally they rev the version number when there's any change.

      Delete
    10. Oh, OK, so then the version numbers you have been posting are not your numbers. Then, what I'm actually asking is: How will we know when you have posted the fixed v. 4.3.27?

      Delete
    11. Because I said I posted it. :P Look at the link, it's already changed.

      Delete
    12. Oh, its already done. OK. thanks!

      Delete
    13. Dang! I just downloaded the new, fixed version - and I still have the same issue. Same wrong responses when running the tests. And now, when I run the test of the version number, of course it comes back with 4.3.27 -- but I can't know if that is the one that was already in there or the new one I just overwrote.

      Here are the Terminal commands and responses:


      Last login: Mon Sep 29 13:43:34 on ttys000
      Unknown:~ XXXXX$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
      this is a test
      Unknown:~ XXXXX$ env X='() { (a)=>\' sh -c "echo date"; cat echo
      date
      cat: echo: No such file or directory
      Unknown:~ XXXXX$ env foo='() { echo not patched; }' bash -c foo
      bash: foo: command not found
      Unknown:~ XXXXX$ bash --version
      GNU bash, version 4.3.27(3)-release (powerpc-apple-darwin8.11.0)
      Copyright (C) 2013 Free Software Foundation, Inc.
      License GPLv3+: GNU GPL version 3 or later

      This is free software; you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
      Unknown:~ XXXXX$ sh --version
      GNU bash, version 4.3.27(3)-release (powerpc-apple-darwin8.11.0)
      Copyright (C) 2013 Free Software Foundation, Inc.
      License GPLv3+: GNU GPL version 3 or later

      This is free software; you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
      Unknown:~ XXXXX$

      Delete
    14. Let me be explicit: I did not update the responses in the blog post for the changes in .27. I did now. They match what you have above. You don't need to do anything -- you're running the most current version and it is behaving correctly.

      Delete
    15. OK, so you have now changed the RESPONSES we look for to be what I am getting. OK. It isn't the download that you will be changing, only your instructions. OK I understand now.

      Delete
    16. Let me be even more explicit:
      - The responses generated by the test cases changed between .26 and .27. I forgot to fix the blog post.
      - The current version is .27.
      - If there is a .28 in the very near future, I will update this post with a different download link, and post a warning blog post to go look, just as I did today. Ordinarily I'd do a new post, but I'm updating this because people are linking to it.

      As far as you're concerned, you did everything right.

      Delete
  9. I have tried to update bash using this method, but for some reason, it seems to have failed somewhere.
    I am left with this message in terminal

    login: /bin/bash: Permission denied

    [Process completed]

    Any ideas?

    ReplyDelete
    Replies
    1. You probably forgot the chmod step. You might be able to get around it this way:

      - Press Cmd-Shift-G with an open Finder window. Type /bin.
      - Find tcsh in that list. Double click it.
      - A new Terminal window will open. Type this command:

      sudo chmod +x /bin/sh /bin/bash

      - Quit Terminal completely and restart it. See if that fixed it.

      Delete
  10. Thank you so much, Big Man!

    ReplyDelete
  11. This comment has been removed by the author.

    ReplyDelete
  12. Hi I installed this following every step on my PowerMac G4 running 10.5.8. But I am still vulnerable to the second test. The first and third test did passed so those were fixed.

    But when I run the command: env X='() { (a)=>\' sh -c "echo date"; cat echo

    I get:
    date
    Mon Sep 29 23:26:08 PYT 2014

    both bash --version and sh --version are 4.3.27(3)-release (powerpc-apple-darwin8.11.0)

    Please help me. Thank you so much!!

    ReplyDelete
    Replies
    1. You didn't delete the file 'echo' when you retested it.

      Delete
    2. Im dumb! Now all 3 tests passed! Thanks a lot!!!

      Delete
  13. Thanks again for updated patch and I hope you will continue to provide updated PCC patches for BASH as are currently 4 public vulnerabilities and one supposedly non-public vulnerability according to https://github.com/hannob/bashcheck.

    ReplyDelete
    Replies
    1. Yes. I'm waiting for the official patch, but the updates are occurring privately and I won't be able to see them until there is a public update.

      Delete
  14. Thank you for the informative and straight-forward instructions. My good old Snow Leopard installation is much happier knowing that most of the vulnerabilities are now patched … no thanks to Apple.

    ReplyDelete
  15. Thanks you for continuing to help support those of us with PPC systems.

    I wanted to provide some feedback based on my patching with 4.3.27-10 on OS X Tiger 10.4.11.

    1. Pre-Patch: All tests confirmed as vulnerable
    2. Patch applied as stated in your instructions. No apparent issues or error messages received.
    3. Post-Patch: Test 1 and 3 confirmed as no longer vulnerable. Test 2 however is still echoing the current datetime of the system.

    bash --version = GNU bash, version 4.3.27(3)-release (powerpc-apple-darwin8.11.0)

    I decided to resurrect my G5 as a dual Tiger/Leopard boot to allow my wife to get back into graphic design. She learned on Quark and while we have a valid license of InDesign her comfort zone is Quark. I'll be patching Leopard next and will post my results.

    ReplyDelete
    Replies
    1. 10.5.8 Patch Results: Everything ran and tested listed in your original post. System now showing Tests 1, 2, and 3 are no longer vulnerable.

      Delete
    2. You forgot to delete the 'echo' file before you re-ran test #2. All of them check out on my 10.4 systems here.

      Delete
    3. Yep, that was it. No more running these late after a long day of work. My apologies and many thanks for putting this together.

      Delete
  16. This has been the only instruction I found only that includes a test along with the update to insure the fix actually fixed something. Thank you for this post. I spotted another post first that required downloading xcode. This was far simpler.

    ReplyDelete
    Replies
    1. P.S. - - The second "only" should read "online." Gotta love typos with no edit ability. I just wanted to report I installed an update over a previous update without incident. This post fixed an Intel Mac OSX 10.6.8 Snow Leopard from the bash shellshock bug. Thanks again. I love that you are simply updating this one post so that blogger can notify me of the need to install a new bug fix. So far I'm up to the 4.3.28 fix. Smooth sailing so far.

      Delete
  17. As I understand it, this latest fix, 4.3.28, fixes five known problems with bash. However, I see there is a six problem too, although I'm not sure when it was discovered.

    So should we expect another version of the fix to come soon? Your note at top seems to indicate you thought this latest fix covered them all, but apparently it does not.

    The sixth issue is: Exploit 6 (CVE-2014-6278)

    ReplyDelete
    Replies
    1. Links to information on the new exploits is available on the bashcheck page:

      https://github.com/hannob/bashcheck

      Delete
    2. Thanks for that. But I must ask, what does it mean? I read the bit toward the bottom under Recommendations about what is covered in the latest fix. It says yes, the one new bug is not covered. But then it says that the two bugs that are not fixed are not a concern because they are not exploitable -- which seems bizarre, since if not, then they are not a bug. Still, why does it in one sentence say there is only one not fixed, but in the next say two?

      Bottom line: does that mean another fix will be forthcoming? Or is it saying that, whether it is one or two bugs, neither will be fixed because they are problems that are not problem?

      Delete
    3. -6271 and -6278 are covered by Florian's patches, which are in this version. You can run the test cases yourself, but I don't see the utility of doing so here, since his patch covers lots of potential problems.

      http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html

      Delete
    4. Err, -6277, but -6271 is also covered, of course.

      Delete
    5. OK, so you say it handles all issues known to date. Thanks, that's what I needed to confirm. Good that you added that at the top too.

      You have been great --- a great service. And I especially appreciate how promptly you reply to posts.

      Delete
    6. Thanks, but the last two vunerability patches are not functioning properly. Should I revert to old bash? Mac Mini (2010) 10.6.8

      Delete
    7. "Not functioning properly" is not terribly specific.

      Delete
  18. I have never used Terminal. I'm running Snow Leopard on a Sept. 2010 15" MBP. I am fanatical about having multiple backups. Can someone please/why hasn't anyone yet post(ed) an installer version of this patch so I can avoid messing about in Terminal?

    Do the patches above need to be installed in sequence (4.3.26, then .27, then .28), or can I just skip ahead and install 4.3.28?

    ReplyDelete
    Replies
    1. You can install 4.3.28 without installing any of the others. They are all stand-alone.

      Delete
  19. Vulnerability 1-3 are patched, but testing vulnerability 4 and 5 still shows vulnerable. 4.3.10-28.4u on OS 10.6.8, Mac Mini (2010).

    ReplyDelete
    Replies
    1. All five tests check out on my 10.6.8 mini and my 10.9.5 MacBook Air. Please post your output and the results of bash --version.

      Delete
    2. After restart, all is good here! All vulnerabilities covered! :-)

      Delete
  20. Thank you so much for your very much appreciated support to help the Mac community and your straight-forward instructions for installing the shellshock patch.

    I just installed patch 4.3.28 and all five tests passed perfectly fine on my old MacBook Pro running OS X 6.8.

    Just a sidenote: When checking the fourth vulnerability (before applying the patch) by entering the command (copied 1:1 from your blog post):

    bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "vulnerable"

    the terminal output was:

    Segmentation fault
    vulnerable

    instead of the warning lines as expected.

    However, after applying the patch and re-entering the fourth vulnerability check the terminal printed exactly the 14 lines as expected, one for each <<EOF.

    Not sure if the first output "Segmentation fault" is of any importance. I'm not much of a terminal guru.

    So again, a thousand thanks to you!

    ReplyDelete
    Replies
    1. I got the same “segmentation fault” before patching. Now ok.

      Delete
    2. As noted above, with crashes like that, the exact output may vary.

      Delete
  21. OK I screwed it up. I didn't decompress the .gz file and ran all commands. Ended up with:
    login: /bin/bash: No such file or directory
    [Process completed]

    So I'm guessing I need to restore the old file and go again, just not sure how.

    ReplyDelete
    Replies
    1. Not sure if this is the actual issue, but if it is, this should work:

      - Open a Finder window.
      - Press Cmd-Shift-G. Type /bin.
      - Rename bash_old to bash.
      - Restart Terminal.

      Delete
  22. I also did this:

    sudo chmod -x /bin/bash_old
    sudo chmod -x /bin/sh_old

    It shouldn't really be necessary, but doesn't hurt to take precautions.

    ReplyDelete
  23. Just curious... is there a 4.3.29 in the pipeline?

    http://ftp.gnu.org/gnu/bash/bash-4.3-patches/

    ReplyDelete
    Replies
    1. 4.3.29 appears to address CVE-2014-6277 (at least). However, the test cases I have available do not succeed against 4.3.28 anymore because of the additional armouring of environment variables from previous patches, so I'm not sure if it's actually fixing anything (let alone anything exploitable). It certainly does not crash or misbehave, so I'm taking a wait and see approach for at least a couple days on this one rather than churn people unnecessarily.

      See also http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html

      Delete
  24. Is anyone else having problems post fix? I am running 10.6.8 on a mid-2009 macbook pro. When I rebooted at the end of the install I had to power off to get it down, and had an fsck error on reboot. I had 4 or 5 kernel panics or hangs on startup or not waking from sleep on Thursday, and then today I had to reboot 3 times to get it to wake from sleep.

    I do notice that my original bash and sh are not exactly the same file:
    -rwxr-xr-x 1 root wheel 1346544 Jun 24 2010 /bin/bash_old
    -r-xr-xr-x 1 root wheel 1346624 Jun 24 2010 /bin/sh_old
    while on my 10.4.11 and 10.5.8 machines they were the same.

    ReplyDelete
    Replies
    1. Cathy, this sounds more like a hardware problem. If I were to bet, I'd bet your hard disk is trying to fail.

      For the record, however, my 10.6.8 Mac mini has had no problems.

      Delete
    2. Cathy, I have had zero problems post fix. I have an Intel iMac running on 10.6.8 OS X. I hope you did a backup before the fix. I had a hard drive failure before and I missed these kinds of warning signs. In hind sight I would stop using the computer as normal and use software like TechTool Pro or get someone to look at it physically. Good luck.

      Delete
    3. Yes, these are the same sorts of symptoms that I was having before my disk failed 2 years ago, but my machine had been rock solid right up until 3 minutes after I replaced the bash and sh executables. Perhaps a coincidence... If it keeps up I will track down the source code and try to make my own build, and see if it's better. Or go back to the old executables and see if that fixes things. I also had a 10.6.8 xserve lock up yesterday morning, but the other 9 servers that I installed on have been rock solid.

      Delete
    4. I would have great difficulty believing they could cause kernel panics; they're userland applications and they don't do anything special with Mach or XNU. Not saying it's not possible, but unlike TenFourFox which does get its hands a bit dirty to work around bugs in the OS, this is pretty much all straight cross-platform POSIX-compliant code.

      Delete
    5. Ever since I bought my first macbook pro which was 2006 and it might have been running 10.3 back then, the operating system has had more or less problems waking from sleep. There are all of the permutations of sleep selected from the menu vs sleep by closing the lid, go to sleep with it plugged in or not, wake up plugged in or not, knock the plug out while it's asleep, etc. etc. etc. And of course I've got my machine set so that only the display sleeps if it's plugged in. It has been really quite good since about 10.6.6. But I am certainly willing to believe that the machine and/or display goes to sleep and/or wakes up via shell script, and I may be hitting some funk there. While I have had kernel panics, I've also had the machine mostly just go to sleep and not wake up.

      I pretty much always boot into single user mode and run fsck after a crash, and the only time I got an fsck error was when I had to crash the machine after I copied in the new binaries and hit "shut down" and it hung at the white screen for about 10 minutes. Yesterday I couldn't get it to wake up, so I mashed the button, booted into single-user mode and used applejack to run fsck (there's a shell script), then restarted, logged in, and it kernel panic'd as the desktop started to load. Restarted, kernel panic again. Restarted, fsck, restarted, and it's been up since. Last night when I went to bed I put it to sleep via the menu, and it woke up this morning without the slightest problem -- no problems today.

      Delete
    6. In case this is really a problem with the new version of bash and someone else is having it, I have gone crash-free since Sunday night. When I move the computer -- i.e. I put it to sleep and pack it up and take it somewhere so it's unplugged -- I select "Sleep" from the apple-menu rather than just closing the lid. The main problem is not forgetting!

      I suspect that there is some complex interaction between what apps I'm running, and whatever process runs differently with a lid-close sleep rather than a menu-selected sleep with the new version of bash. I'd much rather have to remember to use the menu to put it to sleep than risk the older version...

      Delete
  25. Hoping you can help me recover from a novice error. I placed the patched Bash on my desktop rather than home folder, then proceeded through the various commands. Install failed, old Bash moved to the backup directory (I think) after the command:
    sudo mv /bin/bash /bin/bash_old
    Password prompt followed. The remaining 3 sudo commands didn't seem to do anything.
    After reboot, now when I open a terminal window I get:
    login: /bin/bash: No such file or directory
    And can't repeat the process from the beginning (with the patch file in the proper home directory), as I can't type or copy-paste into the terminal window.

    I do have a Time Machine backup of my hard disk (including all system directories etc.) but thought if i knew where the old Bash had been moved to, I could simply move it back.

    Sorry for being a bit of a noob...

    ReplyDelete
    Replies
    1. Not sure if this is the actual issue, but if it is, this should get you back to a working state:

      - Open a Finder window.
      - Press Cmd-Shift-G. Type /bin.
      - Rename bash_old to bash.
      - Restart Terminal.

      However, I'm not sure what you did wrong to get to that point since I don't have a log of the exact commands you entered.

      Delete
  26. For those who would prefer to have an official, Apple--provided bash fix, I ask:

    Can the fixed bash that Apple put out for 10.7 and above be used to fix the lower OSs, including down to at least 10.4 PPC?

    I ask because it occurs to me that the bash offered here supposedly is good on any OS X from 10.4 and up, PPC and Intel, through 10.9. If so, it makes sense to me that we could instead just use the official Apple bash and install that on any of the OSs with the instructions from here. (But I will say, I have confidence in one provided here by the TenFourFox people -- although I don't know anything about the source it camefrom. But I emphasize, I have no issues with it.)

    Does anyone know? And, is the Apple one as good as the one used here -- maybe Apple did the fix differently and not so good?

    ReplyDelete
    Replies
    1. As far as I understand, the patches from Apple are only compiled for 64-bit Intel Macs - they won't work with 32-bit Intel 10.6 machines or anything older. Apple is also using an older version of Bash than the one provided here by TenFourFox... the Apple version is 3.2.53, whereas the ones here are 4.3.28 and compiled in a way that they will work on both PPC & Intel machines.

      I'd stick with the TenFourFox versions here, personally.

      Delete
    2. Apple does not use bash 4.3. I've chosen to do so here to pick up other bug fixes and improvements. Their version is substantially earlier. 4.3 is designed to be upwardly compatible and other than one report of an old version of a utility having difficulty with its installer, I have had no compatibility issues reported to me. You can temporarily roll back since the steps here save your old version of bash.

      In general, you should use the Apple provided fix. For people on a supported version of OS X, the binary I offer is a stopgap. My 10.9.5 MacBook Air uses the Apple fix.

      For people on 10.4-10.6, there is no support from Apple, and I stand by this binary (it's installed on all of my 10.4-10.6 systems). The 10.7 binary may or may not work on earlier versions of Intel Mac OS X depending on what it's linked against, and it will definitely not work at all on a Power Mac. Frankly, I would be very surprised if it worked even on Snow Leopard, let alone anything earlier.

      Delete
    3. OK, thanks. Since I'm talking of a 10.5.8 PPC Mac here, then that means the Apple fix can't be used on it (I suppose for the reason SyneRyder says, the Apple fix is strictly for 64 bit). OK, so then all other consideration is moot for me.

      Delete
    4. Any opinions about whether to use this binary or the Apple-supplied binaries for 10.7-10.9 machines? Yes, I have a preference for the Apple-supported product, but 3.2.53 seems pretty far behind...

      Delete
    5. The differences between 3.2 and 4.3 are primarily enhanced scripting capabilities, but there are some bug fixes which the 3.2 patches do not cover; see http://wiki.bash-hackers.org/bash4

      That said, on my one and only 10.9 system, I am using the Apple bash, though partially for reasons of comparison.

      Delete
  27. Just to ask, while I doubt this bash fix has anything to do with it, but I must ask to be sure:

    After doing the bash fix, the next time I tried to drag and drop a photo directly into my Gmail compose window, that function would no longer work -- it would not insert. That is, when using Safari 5.0.8 on PPC G4 running OS 10.5.8. The function had still worked at least shortly before doing the bash fix.

    I don't know that the bash fix is the least bit related, but since that is what I did on my side, I have to ask if anyone else lost that function in Gmail running from Safari 5 after doing the bash fix. I note, I can still drag and drop directly into the compose window in Gmail if I instead use TenFourFox 31.1.1. (I much prefer Safari because it is faster, especially when I try to open my Bookmarks list.)

    ReplyDelete
    Replies
    1. I hereby confirm that drag’n’drop pictures into safari gmail no longer works, neither on 10.6.8 G5, nor 10.6.8 Intel 32 after applying the patch. Any fixxx but reverting?

      Delete
    2. I don't mean to be short with you, but Safari doesn't even call bash or any shell. How about reverting and seeing if it makes any difference first?

      Also, 10.6.8 doesn't run on G5.

      Delete
    3. That wasn;t beeing short; that's theinformation Ineeeded toknow.

      I just deinstalled the replacement bash and reinstalled the original (and tested, to make sure original was in place, and yes, it failed the tests, so it was the original).

      After doing so, the problem with Gmail insertions into the compose window remains. So, the issue is not the new bash. (I think Gmail happened to do something right about the time I replaced the bash that served to stop that function in my Safari 5.0.6, on a G4 PPC Mac running OS X 10.5.8 Leopard.) Well, it just occurred to me that I did not do a restart before testing Gmail. Dang!

      Delete
    4. That seems a more likely explanation, especially since Google has done such things before without warning.

      Delete
    5. Ok, confiming that you now need Safari 6 or higher to drag’n’drop photos to Safari gmail, which in turn demands 10.7.5.

      You’re right: Has everything to do with gmail dropping support for Safari 5.x.x, and nothing to do with the patch. Also, my G5 sure boots 10.5.8, not 10.6.8 as I incorrectly wrote.

      Delete
    6. I don't want to stray from this page's topic, so real fast, to clarify for you: You can still drag and drop in Safari 5.0.6. You simply can't do it directly to the compose window, you have to use the photo-insert button at the bottom of the compose window and drag into the window that opens -- an extra step.

      Delete
  28. Thanks heaps for this!

    Looks like there are some vulnerabilities fixed in patches 29 & 30:

    29: "When bash is parsing a function definition that contains a here-document delimited by end-of-file (or end-of-string), it leaves the closing delimiter uninitialized. This can result in an invalid memory access when the parsed function is later copied."

    30: A combination of nested command substitutions and function importing from the environment can cause bash to execute code appearing in the environment variable value following the function definition.

    ReplyDelete
    Replies
    1. Yes, I'm aware. It's not clear that either patch addresses something not addressed by the previous ones (if you think otherwise, please demonstrate a test case that works against 4.3.28). I'm taking a wait-and-see approach as described above. Eventually I will incorporate them, but I think there are more patches to come.

      Delete
  29. Thank you so much for documenting this and making the binary available. One suggestion though: your instruction to make a copy of the unpatched binary as /bin/bash_old and /bin/sh_old leaves a vulnerability, as an attacker can try to execute that old binary. It would probably be best to add sudo chmod -x /bin/bash_old and sudo chmod -x /bin/sh_old commands so that the copies can't be executed.

    ReplyDelete
    Replies
    1. Your point is well taken, and was already suggested at least once, but given the number of people who made an error during install it seems prudent to consider that recommendation at a later step so that the Finder can rescue them.

      Delete
  30. Here’s for the crazy ones, the misfits, the trouble makers, the round pegs in the square holes. The ones who see things differently:

    The Missing Bash Update Installer For Snow Leopard

    ReplyDelete
  31. First, huge fan. I love that TenFourFox continues to be updated and I greatly appreciate all the time and effort Cameron puts into keeping older version of OS X relevant and usable.

    Now, a possible bug in bash-4.3.28-10.4u …

    When I ran this bash vulnerability tester script (note, people in the future: someone else may eventually own this domain, so use with caution)…

    curl https://shellshocker.net/shellshock_test.sh | bash

    …it said that the first one (CVE-6277) was still exploitable on my 10.6.8 machine. Is their test incorrect?

    Incidentally, when I compile and install my own based on Apple's 3.2 source and patches 52 through 57, I get a "not vulnerable" report for all 6 of the vulnerabilities for which this script currently tests.

    ReplyDelete
    Replies
    1. You mean the second one, which is CVE-2014-6277, and you actually tested something else. I asked for a test case to trigger -6277 in .28 (see comments above) because I couldn't find one. This one does work. The reason your build passes is because you have the equivalent patches to .29 and .30. Now that I have a test case, we'll proceed to .30.

      If you can compile your own, that is obviously preferable.

      Delete
  32. What happened to my question (and explanation) about a serious problem with Terminal after making a mistake doing this bash fix? Posts are supposed to get moderated now before going online, but I posted several days ago, and it still is not moderated and online. Do I need to write and post all over again? Terminal no longer will work, won't let me type anything into it -- if I can fix that, I think I can then fix the mistake I made.

    ReplyDelete
    Replies
    1. I never saw your other reply. If you are getting the same message as David Ubogy above, however, then the same steps should work.

      However, this post is now almost a month and a half old -- I can't monitor old threads forever, and this was always provided without any warranty or guarantee of support. So that others don't come here looking for rescue, I will close comments on this post. If you are not comfortable with the commands above, or do not feel you could rescue yourself if something goes wrong, you shouldn't do this.

      Delete