Mobile Browsers: Trouble Comes in Threes

In the last week there have been a few vulnerability disclosures for mobile web browsers. These threats affect a number of smart-phone platforms: Android (Google), WebOS (Palm), and iOS (Apple). Although all three platforms have their own apps and environments, it’s interesting that they’re all vulnerable through the same entry point of the mobile browser.

Data stealing: Android

The vulnerability discovered by security researcher Thomas Cannon can be used to steal data from the SD card. The proof-of-concept website downloads an HTML file containing JavaScript to the phone and then runs the file. This locally loaded file then has access to files stored on the SD card. The attacker’s site can call the JavaScript to upload a file with a known path.

The key to the vulnerability is that locally loaded HTML files are run in the browser with fewer restrictions than web-loaded pages. This doesn’t allow access to the entire phone, just to directories accessible by the browser. The risk is that a number of applications store their data at known paths on the SD card and all of those would be available to attackers.

Although it’s recommended that users turn off JavaScript in the browser to avoid being affected by this vulnerability, this step would break some web applications and tend to reduce the overall usefulness of the browser.

XSS and mobile botnets: WebOS

Orlando Barrera and Daniel Herrera, researchers at security consultancy SecTheory, have discovered a number of bugs in the Palm Pre’s WebOS (Version 1.4-2.0). WebOS is similar to iOS before Apple allowed native apps; every application on the Palm Pre is a web application.

The researchers found a cross-site scripting (XSS) flaw, a floating-point overflow bug, and a denial-of-service vulnerability. The XSS flaw is in the contacts app. A field in the sync window of the app did not sanitize its data, allowing the researchers to insert code that gives them access to and a copy of the contacts database (containing email addresses, email, contacts, etc.). They were also able to implement a keylogger and methods for exporting data to an attacker. They have developed the the basic framework for implementing a botnet on Palm Pre devices.

Palm has patched the XSS vulnerability in the upcoming WebOS 2.0 release, but the other two flaws are not yet fixed.

Spoofing sites/phishing: iOS

To round out our trio, security researcher Nitesh Dhanjani points out the possibility of spoofing websites in Safari on the iPhone. Safari hides the address bar after a site has completely loaded. This lets attackers present their own versions of the address bar that lists a banking or shopping site rather than their own. Dhanjani has provided a proof-of-concept site for the iPhone that masquerades as a banking site.

The user must scroll the page up in order to see the original address bar.
Without the warning notice on the proof-of-concept site, an unsuspecting user could easily fall victim to phishng.

The issue with this vulnerability is that unlike the Android browser, Safari removes one of the indicators of a possible phishing attack. The absence of the address bar allows for more immersive web applications that appear almost exactly like native apps, but it also allows attackers to take advantage.

Patches: a compete solution?

A number of these vulnerabilities have been patched, but this does not secure all of the affected devices. Embedded systems and mobile phones in particular can’t be patched as easily as your desktop computer. For over-the-air patches there are costs involved in bandwidth, transmission time, and device downtime that argue against frequent updates. These updates also do not include testing and QA on every affected device. The additional work can result in the “fixed it in CVS/SVN/etc.” situation–in which developers have fixed a bug in the project’s source code but the fix hasn’t yet reached current compiled programs.

The outlook with smart phones isn’t quite as stark as with phones with fewer features. Whereas simple phones have almost all their system software and applications in the firmware, smart phones tend to have theirs on easily writable storage. A buggy browser can be fixed with a small signed update, rather than requiring the phone firmware to be reflashed. Or we may see a move toward placing thin firewalls/IDS layers between applications and potential attack vectors. As more vulnerabilities are discovered in mobile applications, these small targeted patches may become the norm.

2 comments on “Mobile Browsers: Trouble Comes in Threes

Leave a Comment

nine − six =