Archive for September, 2009

Gruber does a snow job on Snow Leopard

Saturday, September 5th, 2009

John Gruber holds Apple blameless for shipping Mac OS X 10.6.0 with an outdated version of Adobe Flash Player, a version with known vulnerabilities that have been exploited in the wild. The essence of his absolution is the following timeline: “Adobe released version of Flash on July 30. Snow Leopard went GM on Friday August 7″.

It is true that Adobe released Flash Player to the public on July 30. However, with regard to the version of Flash Player included with Snow Leopard, that date is largely irrelevant. On July 21, Adobe released a security bulletin to the public: “Adobe is aware of reports of a potential vulnerability in Adobe Reader and Acrobat 9.1.2 and Adobe Flash Player 9 and 10.” The next day, there was a public follow-up: “A critical vulnerability exists in the current versions of Flash Player (v9.0.159.0 and v10.0.22.87) for Windows, Macintosh and Linux operating systems, and the authplay.dll component that ships with Adobe Reader and Acrobat v9.x for Windows, Macintosh and UNIX operating systems. This vulnerability (CVE-2009-1862) could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild via limited, targeted attacks against Adobe Reader v9 on Windows. We are in the process of developing a fix for the issue, and expect to provide an update for Flash Player v9 and v10 for Windows, Macintosh, and Linux by July 30, 2009″.

It is crucial to note that these were all public releases. Since Apple ships Adobe Flash Player with Mac OS X, Apple and Adobe undoubtedly have a private relationship. One would presume that Adobe privately discloses security vulnerabilities in the OS X version of Flash Player to Apple in advance of public announcements and that Adobe privately provides Apple with versions of Flash Player to test on OS X prior to public release. If these things do not occur privately, then both companies ought to be blamed for failing to follow industry best practices.

I’m not sure where Gruber gets the August 7 date. (Perhaps an email from Phil?) Snow Leopard build 10A432 was seeded to eligible ADC members on August 12. If Apple had already declared build 10A432 the GM before seeding it to developers for testing, that would be completely irresponsible (though sadly, not unprecedented). In any case, if the 10A432 seed had turned up a show-stopping bug, Apple could have un-declared it GM. Is allowing an attacker to take control of a system via a web browser not a show-stopper? Gruber asks, “Should Apple have postponed Snow Leopard for another month?” Despite the rhetorical nature of the question, I’ll answer: maybe they should have. Or at least, they should have postponed it 4 days. At WWDC, Apple told us that Snow Leopard would be released in September. Last time I checked, August 28 is not in September. Even delaying Snow Leopard a month would have allowed Apple to ship on time, in September.

Setting aside these more relevant dates, let’s just accept Gruber’s 8-day window for the sake of argument. “Does anyone really think that Apple should have replaced the single-crashiest piece of software in Mac OS X with a new untested version just eight days before going GM?” Yes, I do. We’re not talking about a major update here — obviously Apple should not switch from Flash 9 to Flash 10 eight days before GM. Apple had already pulled the trigger on Flash 10 for Snow Leopard. When security vulnerabilities come to light, fixes must be released quickly. Eight days of testing the update from Flash Player to really should have been sufficient for Apple. If a critical vulnerability was discovered in Mac OS X, Apple should be able to ship a fix within 8 days, if not sooner. Indeed, there were 8 days between Adobe’s security bulletin and the release of the updated Flash Player.

Apple’s record for shipping timely fixes to security vulnerabilities is poor. For example, Apple ‘distinguished’ themselves by being the only vendor in the world to fail to join the coordinated effort to release a fix for the Kaminsky DNS vulnerability on all platforms on the same day. Instead, Apple took its own sweet time, which was particularly egregious for Mac OS X Server customers. (Though I use OS X on my personal computers, I’m glad my web host does not use OS X on their servers.) I personally was aware of the ‘Safari RSS’ vulnerability for months while it remained unpatched and could have easily exploited any visitor to my web site if I had wanted. Fortunately for you, I’m not malicious. Not criminally malicious, anyway.

Apple hot-swapped Mac OS X 10.5.8

Tuesday, September 1st, 2009

There has been some confusion in the net-o-sphere over the existence of two Mac OS X 10.5.8 builds: 9L30 and 9L31a. I think it’s time to clear up that confusion, now that Max OS X 10.6.0 has been released and nobody cares anymore about 10.5.x.

The Max OS X build version is stored in the following file on your hard drive:


On my machine, the build is 9L30. I installed 10.5.8, as usual, via the combo updater (because I’m a paranoid superfreak who also repairs permissions and offers sacrifices to Demeter). This was a prudent three days after 10.5.8 was released, though the combo updater was downloaded two days after release.

Lately (in the Holocene epoch), the Mac OS X installers have come in ‘flat’ package format (i.e, “smooth and even; without marked lumps or indentations” or “lacking interest or emotion; dull and lifeless”). This makes them opaque to the casual observer. Fortunately, I am Klondike Kat. The installer .pkg file is actually a xar archive that can be read and extracted with /usr/bin/xar. To extract the package contents into the current working directory:

$ xar -xf /Volumes/Mac\ OS\ X\ Update\ Combined/MacOSXUpdCombo10.5.8.pkg

This gives us an ‘old-style’ (Pleistocene) .pkg file whose contents we can view in Finder. The package contains, among other things, a Payload. Be careful not to ignite it, otherwise you may require intensive care, if not AppleCare. The Payload is a gzip archive, so I slapped a .gz extension on the file and gunzip‘ed it. After extracting that archive, you’re left with … yet another archive. (Apparently the Matryoshka method of software distribution.) The new Payload can be read and extracted with /bin/pax:

$ pax -f Payload -r *SystemVersion.plist

The SystemVersion.plist from my original installer is for build 9L30, but the one from the installer I downloaded today is for build 9L31a. Thus, we have to conclude that Apple ‘hot swapped’ Mac OS X 10.5.8. That is, they switched Mac OS X builds after release without bumping the version number.

Why Apple did this remains a mystery. Usually software developers do it when they discover an issue shortly after release but don’t want to go to the trouble of making a public announcement of a new version. What was the issue, and do those of us who have build 9L30 installed still suffer from the issue? For the answer to those questions, you’ll have to read the release notes. ;-)