Fast phone patching still a fantasy

Researchers are focusing on vulnerabilities in cell phones, but manufacturers and carriers are still stuck in the 90s.

By Robert Lemos

April 07, 2011 — CSO —

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.

RESOURCE CENTER