And the bash goes on: 4.3.27

Another problem in bash, another bump, now updated to 4.3.27. Since the recommended patch is now officially part of upstream, I updated the link and instructions in the previous post.

Ars goes back to the future

Ars Technica subjected Andrew Cunningham to getting his work done on an 800MHz TiBook (in OS 9 and in 10.5). Admittedly, I, too, would find an 800MHz TiBook a bit trying, though I would not have installed Leopard on it. My slowest daily driver is the 1GHz iMac G4 and even that doesn't do much more than basic browsing. My 12" iBook G4/1.33 is about the slowest I'd like to be using for typical work. Fortunately, the quad still acquits itself very well!

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.

Bashing bash: updated universal OS X bash available as a public service

UPDATE THE SECOND: People are unclear about what I mean by "incomplete." I mean, the existing patch for bash is not complete. Even for the list of commands floating around to build from source (seen on MacRumors and other sites, which requires Xcode), you won't be protected from the second variant of the attack. You'll have to wait for that final patch. Your call whether to continue with the below. Updated to fix /bin/sh as well.

UPDATE: Looks like the fix is incomplete; someone found a way around it. I'll post an update with the newer version when they decide on it, but you can fix the immediate bug now with the steps below.

I hate bash. I prefer tcsh. But Apple made it the default, and now 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 there will be no update for us. The vulnerability appears to exist on all versions of OS X.

I thought about this for awhile on how much of an attack surface we're exposing. Servers that might run shell scripts as CGIs would be very high risk, but if you're actually using a 10.4 or 10.5 machine as an externally facing web server you really need your head examined. Similarly, there's the possibility of getting privileged setuid scripts on a multiuser system owned, which again would be primarily an issue for servers.

The risk is less clear on single user workstations, the situation in which I imagine most Power Macs exist, which either run bash purely as a login shell or certain programs may call out to it to accomplish certain system tasks. Realistically, I don't see a large attack surface here, but clever little sneaks might find a way and besides, 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.

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 bash, but your built-in bash is still vulnerable unless you replace it. This is designed to accomplish that.

WARNING: The following steps assume you know how to use Terminal.app and some basic Unix commands. If you don't, get help.

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. This has been superseded Download the patched bash 4.3.25. 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.25-10.4u.

3. 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.

4. In that terminal window:
   • exec tcsh
   • chmod +x bash-4.3.25-10.4u
   • sudo mv /bin/bash /bin/bash_old (enter your password)
   • sudo cp bash-4.3.25-10.4u /bin/bash (enter your password if needed)
   • sudo mv /bin/sh /bin/sh_old (enter your password if needed)
   • sudo cp bash-4.3.25-10.4u /bin/sh (enter your password if needed)

5. Test it stuck by trying the statement again:

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

   It should print

   bash: warning: x: ignoring function definition attempt
   bash: error importing function definition for `x'
   this is a test

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

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

What the security issue was all about

Mozilla has released 32.0.3 and the official advisory, so now we can talk about it. What got fixed in 31.1.1 is a flaw in verifying signatures of RSA certificates, most importantly such as those used to confirm the identity of secure sites. By exploiting this bug the proof of concept caused Firefox to accept a forged certificate, which facilitates information stealing and man-in-the-middle attacks. The forgery is an interesting variant of a well-understood older attack vector called the Bleichenbacher attack, named after the crytographer who discovered it, or more colourfully the "million message attack," itself a specific form of an adaptive chosen-ciphertext attack. Through a combination of flaws, a clever attacker could synthesize a completely bogus "valid" certificate in a relatively small amount of computing time and use it to impersonate victim servers to steal credentials and data.

The general type of flaw suggests other crypto libraries may be vulnerable to this specific problem or a related form of it. That said, this problem has existed in Mozilla code since at least 2006; earlier versions don't use the same ASN.1 parsing code, but almost certainly have other problems related to certificate verification. You are strongly advised to update, because the relative ease with which a certificate can be forged will put yourself at much greater risk in the near future if you don't (24.7.0 is vulnerable, as is every prior version of TenFourFox).

31.1.1 available

Downloads of 31.1.1 are available -- release notes are pending Firefox's release since the security information is embargoed. Please try them on your system. They will become live as soon as Mozilla does so for mainline Firefox and ESR. I'll have more information for you then.

Heads up: 31.1.1 imminent

Mozilla is chemspilling for a high-priority security issue which we are vulnerable to; this will force a 31.1.1 build, on which I will also take all the current security and stability fixes Mozilla has landed on 31ESR to date. The G5 is currently chugging out release candidates hopefully for release to you the testers tomorrow evening to become live on Thursday.

For Chrome, 32 bits are not enough

Google is touting its 64-bit build of Chrome for OS X, scheduled for rollout with Chrome 39 in November. Almost a whisper by comparison, though, is what will happen to the 32-bit build. Well, it's very simple: it won't exist. This is the end for the 32-bit Intel Mac as far as Google is concerned, even though those Macs can run 10.6, which Chrome, at least for the moment, still supports. Chromium might still build, but I wouldn't bet on it.

Besides the obvious -- no 32-bit browser -- there are some other knock-on effects, the most important being that 32-bit plugins won't work either. This is not a big deal presently since the major plugins have 64-bit versions now, but Google is completely removing NPAPI plugin support later this year as well. This leaves its perverse little PPAPI plugin support, which only Chrome can run, to maintain Flash compatibility using its bespoke in-browser version; Mozilla, Microsoft and Apple have all uniformly refused to support PPAPI. That's okay with Google, because soon their Native Client implementation is going to take over your desktop with Android apps anyway.

As it stands, Firefox is a fat x86 binary with 32-bit and 64-bit versions, but historically when Google has withdrawn support Mozilla has been quick to follow, and Google's decision is already being discussed on the Mozilla developer channels. Currently the only thing really forcing 32-bit support is the need for Silverlight for Mac, which doesn't exist in a 64-bit version. Since Chrome won't be supporting NPAPI plugins of any kind soon, they don't have that limitation; should Mozilla find a HTML5 workaround for sites like Netflix, or the userbase drop enough, you can confidently expect the end of 32-bit support on OS X from Firefox as well.

This is important for us in two respects: we rely on a lot of 10.6 code still, and a 64-bit only build clears the way to end 10.6 support; and we are a 32-bit hybrid Carbon/Cocoa application. The only 64-bit Power Mac is the G5, but even if I limited TenFourFox to the G5 systems exclusively (which I won't do, because at a minimum I myself use the 7450 build also), it still wouldn't work because there is no 64-bit Carbon and 10.4's 64-bit Cocoa support is incomplete. As long as 32-bit builds persist, 10.6 support is likely to remain as well, because they serve no purpose on 10.7+. Once they disappear, I predict Mozilla will drop both 10.6 and 10.7 simultaneously and support only 10.8+. (Remember, Firefox already can no longer be built on 10.6, even though it will still run on it.) We could probably still make much of the cross-platform code work on 32-bit PowerPC because the Linux and Windows tier-1 builds still support 32-bit, at least for the time being, but the OS X-specific portions would become much harder to work with.

On that note, due to my dissatisfaction I've decided to scotch the 33 release and jump to working on 34. (If you want the changesets to build your own to play with, you can get them from the unstable folder on SourceForge. Please note that they are against 33-aurora, which is now 33-beta, so you should expect some merging to be required.) For now, I'm just concentrating on getting to 38, and secondarily on completing the MIPS JIT conversion to PowerPC; 34 is currently crippled by a severe bug on systems without hardware acceleration, but this is biting Mozilla as well, so it is virtually certain they will fix it shortly. 38 is kind of a nice milestone because by the end of 38ESR support, even the last quad G5 to roll off the assembly line will have received a full 10 years of support, from 2006 to 2016. I'd really like to make that, at least, and pick up the important HTML5 and ECMA6 features that are being added such as <picture>.

In other news, I picked up an Apple Workgroup Server 9150 and restored it this weekend. I'm sort of developing a hyperspecialized interest in Apple server-grade hardware, such as it existed, particularly the truly unique Apple Network Servers; while I don't really have much interest in the Workgroup Servers in general because they were rebadged workstation Macs with occasionally different storage loadouts, the WGS 9150 is a legitimately odd chimera of the Quadra 950/Apple Workgroup Server 95 and the Power Macintosh 8100 with some strange attributes of its own. In its prototype form as Green Giant, it was also the testbed for Apple's brief and sorrowful flirtation with NetWare (the so-called "Wormhole" project); it went over so badly with testers that Apple ended up developing Shiner in its place, which became the ANS, and the Green Giant prototype was recycled into the 9150 with MacOS. After stripping it down, cleaning its profoundly grimy contents, applying a bit of steel wool and gentle care to get the yellowing and deep marks out of the plastic, and then replacing the CD-ROM, adding another hard disk and recabling it, it is now sitting next to the G5 quietly installing MkLinux. Why MkLinux, you ask? Because it's period-appropriate, it probably doesn't suck on the 601, Apple actually supported it, and I want to compare it to Rhapsody. Watch for an "ANFSCD" on it in the near future.

Finally, I am concerned that SeaMonkey PPC has halted updates; I haven't seen anything since May of this year. Our Tenfourbird builder from the Land of the Rising Sun has been keeping pace, but SeaMonkey PPC is based on its own code, and it's possible he hasn't been able to keep it working. Hopefully that's not the case, since the looming end of the original WebKit1 will also limit Leopard WebKit users, though I know Tobias will continue to work on fixes and improvements. We need more and better browser support for OS X/ppc, not less.

TenFourFox 33 sort of gets off the ground

This is being typed in TenFourFox 33, which bodes well, but this was a very hard port and I don't have full confidence in it. For one thing, it was a very large merge and overall I had to backout several changes that would break us. While irregexp, the new regular expression engine for JavaScript derived from Google V8, does appear to mostly work after some substantial time spent sniffing out all the test failures and endian problems, it has one big problem in that it can't grow its backtrack stack, used for complex match jobs, without crashing. I suspect an OS glitch; I can't find anything wrong with my generated code yet. Right now the system simply uses a large enough default stack to pass the tests and refuses to enlarge it further. This seems to work, but I can't guarantee it works with every possible addon (Ghostery in particular has had past problems with limitations on regular expressions) and it requires several megabytes of space by default even if it never actually uses it, potentially per compartment. If memory or compatibility pressure becomes too high we can run or at least force Firefox to run without native regular expression compilation, but although that works fine it is very slow by comparison.

In addition, WebRTC's new screen capture code doesn't compile at all on 10.4. I think I have it hacked so that it will work without it and we can still use WebRTC for webcams as we are doing now, but it's all very rickety. The rapid development of that code means further bustage in the near future.

Finally, the one thing I was really hoping for out of Fx 33+, asynchronous pan and zoom where you can move around and scroll the page at least while it is loading and JavaScript is running, won't compile on 10.4 either. Tiger completely lacks any method, even an undocumented one, for turning a CGEvent from an event tap into an NSEvent, and I am so far not able to find documentation on the opaque CGEvent object to be able to fake up enough of it to get scrolling to function. The old CGSEventRecord does apparently have undocumented support, but I can't find any documentation on that either, just some references in code to header files that do not exist in the SDKs that come with Xcode 2.5.

Overall, although it works, I'm not happy with what I had to do to make it work. I'm not sure I'm going to make a release of 33 (other than changesets) -- I might turn this around immediately into aurora 34 and try to get cracking on converting the MIPS IonMonkey JIT because if the stack limitations of irregexp become a big problem, I may need the rest of the Ion JIT to overcome the performance hit we will take by disabling native regular expressions. I think this should be the biggest priority for 38, the next ESR. There may not be much further we can take the browser after that if we even get that far.

The irregularities of irregexp (plus: the resurrection of thule)

31.1.0 is now released to an adoring public, a little ahead of Firefox which apparently releases on Wednesday but I don't see any reason why we should be delayed.

I also made a major breakthrough over the weekend and irregexp, the regular expression engine Firefox switched to in Fx32, is now generating working JIT code on PowerPC. This involved fixing a couple of undiscovered bugs in our JIT and adding support for the PowerPC byte-swapping load instructions (lhbrx and lwbrx) so that irregexp's inherent little-endian orientation could be worked around on our side. It now passes V8, and I think I can get it passing all the tests in a couple more days. This was a must-complete milestone because without it not only will we be unable to implement our new MIPS-based JIT, but we almost certainly won't make the next ESR. This makes our chances much better.

That's the good news. The bad news is that, at least on V8, it seems to be anywhere from 30 to 50 percent slower on compiled expressions than YARR, which we use in 31 stable. It's always hard to assess final performance on a debug build, but I want to make sure that our use of the byte-swapping instructions is not to blame. It may end up being faster to emit code to do a regular big-endian load and then rotate things around with rlwinm and rlwimi, even though that's two or three more instructions in the I-cache; I'm going to do some more testing with that once I have the test suite passing completely. It doesn't look like it's an emulated instruction on G5, thank goodness.

Those of you on ThinkClassic will have already seen this story, and if you're not on TC you should be, but this weekend thule, my long-running Macintosh IIci NetBSD/mac68k server, finally blew its logic board after fifteen years. Most likely it needs a recap, but the good news is, I already had a spare board with fresh caps in reserve for just such a day and thule is running again. When it was the only server in my apartment, it acted as a cross-development machine for my Commodore 64 programs (the 7300 mounted it over AFP and I ran a cross-assembler on it that emitted binaries the 7300's C64 emulator could pick up and run in the debugger), a small file server and a backup repository. Today, a decade and a half later, it still handles internal DNS resolution and AppleTalk services for the classic pre-OS X machines, and even though a 25MHz '030 is glacial by current standards -- especially since I pulled the L1 cache card to improve its uptime -- it has rendered reliable and sterling service since 1999. I see no reason it won't continue to do so on its new logic board. Here's to another fifteen years of putting a classic to work every day.