Apple pushes out critical security fixes for OS X, iOS and Apple TV

Apple has been listening!

Half-listening, anyway.

It’s been said for some time – in articles and in podcasts – that Apple would do well to become both regular and frequent with its updates.

Regular means having some algorithmic predictability for non-emergency updates, such as “always on Tuesday.”

And frequent, in our book, means monthly or thereabouts.

Oracle and Adobe update quarterly, which probably isn’t swift enough these days.

Microsoft famously does updates every month; Firefox updates every six weeks, which, coincidentally but happily for fans of Douglas Adams, is a 42 day cycle.

We’ll suggest six weeks as a minimum frequency, and Tuesdays as a regularity beacon, simply because people are used to Patch Tuesday.

Frequency means you get in the habit of not making your users wait for important fixes, and regularity means you get in the habit of never letting your coding-and-testing operations slip.

Anyway, Apple seems to be getting somewhere towards half way there.

You still can’t tell when you’re going to get your next update, but serious security fixes do seem to be coming more frequently these days.

Like the latest round of patches, published on 22 April 2014 (a Tuesday, as it happens) for Apple OS X, Apple iOS and Apple TV.

Apple TV goes from 6.1 to 6.1.1 and iOS goes from 7.1 to 7.1.1, while OS X versions keep their old numbers but receive Security Update 2014-002.

As with other recent OS X updates, only Lion (10.7), Mountain Lion (10.8) and Mavericks (10.9) get patches.

Dont shoot the messenger, but Snow Leopard (10.6) gets nothing, and is once again at least unofficially unsupported.

It’s possible, of course, that none of the patches are necessary on 10.6, just as there are fixes that apply only to 10.9 and aren’t needed on 10.7 and 10.8.

But at least some of the updates – for example, updates to third party open source components such as Ruby – look as though they aren’t tied to specific OS X versions.

Interestingly, the OS X Security Update also includes Safari 7.0.3, already delivered as an update of its own at the start of April 2014.

So if you skipped that Safari update, which wouldn’t have been wise given the number of remote code execution holes that were fixed (26 in all), you’ll catch up now.

The fixes in Safari 7.0.3 include patches for the remote code execution holes at the recent PWN2OWN competition in Vancouver, Canada.

Those fixes are now now also available to iOS and Apple TV users, with a big update to WebKit, the web rendering engine used in all of Apple’s browser versions, desktop and mobile.

Sadly, some of the security holes fixed in this round of updates have been present since last year, and probably should have been patched long ago, during previous updates.

The scripting language Ruby, for example, patched on OS X in this update, leaps forward from the June 2013 release to the February 2014 version.

The Ruby update closes a remote code execution hole, CVE-2013-4164, that was patched in Ruby itself back in November last year.

Mavericks users have received two lots of security patches since November 2013, with 10.9.1 arriving in December 2013 and 10.9.2 in February 2014.

Similarly, Lion and Mountain Lion users got Security Update 2014-011 in February 2014.

Why then, you have to wonder, was the Ruby patch made to wait so long?

Similarly, why was a critical bug in the sudo command ignored for at least six months by Apple in 2013, even though the bug made it possible for just about any user or process already on the system to grant itself root privileges at will?

Clearly, a regular and frequent update regimen alone wouldn’t solve this problem of laggy Apple patches, but it would provide a clear set of deadlines and target dates for Apple’s security team.

You have to think, “That would surely do no harm.”

By the way, we recommend applying this round of updates sooner, rather than later.

The patches fix multiple holes on all platforms, including some attacks that can be combined dangerously, such as bypassing Address Space Layout Randomisation (ASLR), escaping from sandbox protection, getting control of the browser with booby-trapped JPEG (image) files, and grabbing almighty system power from an otherwise unprivileged process.

A remote code execution bug that can be triggered by a web-borne image to give an external attacker administrative privilege…

…is about as patch worthy as it gets!


Via: sophos

Save pagePDF pageEmail pagePrint page

Leave a Reply

Your email address will not be published. Required fields are marked *