Fast phone patching still a fantasy

The inability of cell phone makers to speed their reaction time to vulnerabilities continues to leave businesses vulnerable to attacks on mobile devices, according to recent research.

While PC software makers have, in general, sped up the creation and distribution of software patches, the complex relationship among suppliers for smartphones has made fixing bugs and distributing the patches difficult. A patch for an Android phone, for example, has to be created by, in many cases, the developers responsible for the open-source component, then included by Google in the Android packages, integrated by the phone manufacturer and distributed by the carrier.

Also see: Touring (and surviving) the mobile app minefield

“It has become more intense because of the different variety of sources for the software that phones use,” says Andy Chou, chief scientist and co-founder for source-code analysis firm Coverity. “All of that stuff is integrated together and put out as a single phone — eventually — and managing updates for that process is very complex and managing quality for the whole thing is extremely complex.”

Coverity has twice scanned the Android source code for defects. The company found 359 software defects — 88 critical issues — in the source code for the HTC Incredible phone in November, and a recent scan of a newer version of the source code still under development found 149 defects, of which 106 were the same issues found previously.

Chou stressed the differences between the scans: The HTC scan was against a phone currently in product and with third party additions to the software, while the other is Google’s development version of the Android operating system. Yet, one point is clear: Defects are not fixed quickly on the platform.

“So far, it has been very hard to get visibility into what has been done to resolve these defects,” Chou says. For example, Coverity submitted four defects to the Android development team, but only one was in code written by the Android developers. While they fixed that one, the other three were in the open-source Linux components of the phone. Only one of the components’ developers got back to Coverity.

Coverity does not measure the exploitability of the defects but classes some as critical. Many of the defects may be resolved in future versions.

The problems are not with Google, but with the traditional development process for phones. Because of the convoluted supply chain for the software in the phone and the carrier’s reluctance to push out potentially problematic fixes, updates are rarely released.

The point is highlighted in the recently published work of two researchers, Collin Mulliner and Nico Golde, from the Technische Universitat Berlin. The pair looked at the vanilla predecessors to smartphones, so-called feature phones, and found that each of six major manufacturers has bugs in their platform. In research released last month, Golde and Mulliner found at least one vulnerability in each platform that could be used to crash a phone remotely using text messages. One bug in the phones of manufacturer Sony Ericsson resulted in the researchers “bricking” the device — causing it to become completely unresponsive.

Most manufacturers have a single operating system for their entire product line, and most often they have not done a security review, says Mulliner. “With one bug you can crash their entire product line,” he says. “So it has a huge impact.”

The software vulnerabilities are rarely fixed, Mulliner says. Bugs that were in devices that were five years old were still present in devices that were just a few months old, the researchers found. While carriers have the ability to do an over-the-air update for the phones, Mulliner says they are rarely, if ever, done.

Figuring out a faster way to patch phones may be difficult. Coverity suggests better source code review to catch bugs before they are put into a product — not surprising considering the company’s business. Mulliner and Golde are working with cellular carriers to develop a list of rarely used SMS functions to filter out to eliminate the threat from the bugs the researchers found.

In the end, however, finding a way to patch smartphone bugs on a regular basis is needed, says UT-Berlin’s Golde.

“I definitely think we need an update process that is done because of security problems and not because of new feature roll outs,” says Golde. “I have not seen a single case where a phone was updated because of a security bug rather than because a new Android version was available.”