Apple exposed iOS users to security threats by taking three weeks longer to patch the same vulnerabilities in the mobile OS that it previously fixed in Safari on OS X, a former Apple security engineer said.
Security researcher Kristin Paget, who left Apple at the end of January for a position at Tesla Motors, strongly criticized her former employer’s software patching practices in a blog post Wednesday.
The researcher pointed out that many of the vulnerabilities fixed in iOS 7.1.1, which was released by Apple Tuesday, were the same ones the company had patched in Safari 6.1.3 and 7.0.3 for OS X on April 1. Many of those vulnerabilities were located in WebKit, the Web rendering engine used by iOS, the Safari browser and other OS X applications, and most of them had been found by members of the Google Chrome security team.
According to Apple’s security advisory for iOS 7.1.1, some of the WebKit flaws could allow attackers to execute arbitrary code when users visit maliciously crafted websites.
“In what world is this acceptable?”
“Apple preaches the virtues of having the same kernel (and a bunch of other operating system goop) shared between two platforms [iOS and OS X]—but then only patches those platforms one at a time, leaving the entire userbase of the other platform exposed to known security vulnerabilities for weeks at a time,” Paget said. “In what world is this acceptable?”
“Apparently someone needs to sit Apple in front of a chalkboard and make them write out 100 lines: ‘I will not use iOS to drop 0day on OSX, nor use OSX to drop 0day on iOS.’,” she said.
Zero-day (0day) refers to vulnerabilities that are publicly known but have no official fix from the affected product’s vendor.
It is certainly possible for attackers to analyze the fixes for one product and create exploits that work against other products and platforms that are not fixed yet, said Carsten Eiram, the chief research officer at vulnerability intelligence firm Risk Based Security, Thursday via email.
According to Eiram, these sorts of patch delays between Apple products are a regular occurrence, especially when it comes to fixing WebKit vulnerabilities.
“We’ve seen for a very long time that Google usually addresses WebKit-related vulnerabilities in Chrome long before Apple does the same in their products,” Eiram said. “My rough impression from looking at WebKit security fixes is that the delay is around two-three months on average—though I’ve seen some much longer. After Google forked WebKit into Blink it seems to be getting worse.”
Apple’s issues affect Chrome as well
Google Chrome used WebKit as its rendering engine until version 27 and has since switched to an engine called Blink that’s still based on WebKit. Because of that, many of the issues found and fixed in Chrome also affect WebKit.
However, Apple is not only slow at patching the WebKit engine itself, but also at integrating those fixes into all of its WebKit-dependent software.
Eiram pointed to the patching timeline for a WebKit vulnerability identified as CVE-2013-2909 as an example. That vulnerability was originally fixed in Chrome on Oct. 1, 2013, then Apple patched it in Safari 6.1.1 and 7.0.1 on Dec. 16, 2013 (two-and-a-half months later); in iOS 7.1 on March 10 (five months later), and finally in Apple TV 6.1 on April 22 (six-and-a-half months later).
“The lack of coordination between Google and Apple is one thing,” Eiram said. “However, Apple releasing fixes for vulnerabilities in some of their products while leaving other of their products vulnerable for a long time is a very curious practice that I strongly disagree with. It’s unacceptable that they’re putting their own users at risk like that.”
Apple did not immediately respond to a request for comment.
Other vendors have faced criticism in the past for similar patching practices. For example, vulnerabilities patched in Flash Player used to remain unfixed for weeks in Adobe Reader, which bundled Flash Player as a library called authplay.dll. Adobe eventually removed the authplay.dll component from Adobe Reader starting with version 9.5.1.
One of the few cases when it can be acceptable to push out a security patch for one product while leaving others vulnerable is if a 0-day vulnerability was being actively exploited to target users of that product, but not users of the other products, Eiram said. However, even in such a case of immediate threat, the vendor shouldn’t wait too long before patching the rest of its products as well, he said.