Google Remote-Detonates Pair of Ne'er-Do-Well Android Apps
Two Android applications that Google claims "intentionally misrepresented their purpose" have not only been removed from the Android Market, but have also been erased from the phones to which they'd been downloaded. The company used its remote delete ability to wipe the apps from users' phones, though Google says the applications were not designed to be used maliciously.
Google announced Thursday that it has remotely deleted two Android applications from users' phones, reasoning that the "practically useless" apps had "intentionally misrepresented their purpose."
The Internet search giant pointed to this action as one of many security controls Android posses to protect users.
The announcement came shortly after the release of a study earlier in the week that claimed a large number of Google apps present security issues.
If Thy App Offend Thee, Pluck It Out
The apps Google removed contravened the Android Market's terms of service, Rich Cannings, Android security lead, wrote on the Android Developers blog.
The two, built by a security researcher, misrepresented their purpose to encourage users to download them. However, they weren't designed to be used maliciously and did not have permission to access private data or systems resources beyond "permission.Internet," Cannings wrote.
The "permission.Internet" command lets apps open network sockets, which could render them vulnerable to Web-based attacks.
The security researchers who made the apps voluntarily removed them from the Android Market, according to Cannings, but Google went an additional step further by remotely erasing the apps from all the Android phones onto which they've been downloaded.
"The remote application removal feature is one of many security controls Android possesses to help protect users from malicious applications," Cannings wrote. In emergencies, dangerous apps can be removed from active circulation "in a rapid and scalable manner to prevent further exposure to users," he wrote.
Android's Security Protections
Android's security architecture doesn't let any application have default permission to perform any operations that would adversely impact other apps, the operating system, or the user, according to an Android Developers blog post on security and permission.
This includes reading or writing the user's private data or another application's files, performing networking access, or keeping the device awake.
Further, Android is a multi-process system in which each app and part of the system runs in its own process. Each Android package file installed on a device is given its own unique Linux ID. This creates a sandbox for it and prevents it from touching other apps or other apps from touching it. This user ID remains constant for the duration of the app's life on the device it's been installed on.
"The application sandbox is an important part of the Android security model," Google spokesperson Jay Nancarrow told LinuxInsider. However, operating systems are complex, and their security depends on a combination of factors, he pointed out.
Most security between apps and the system is enforced at the process level through standard Linux facilities such as user and group IDs that are assigned to apps. Further features are governed by a permission mechanism that enforces restrictions on the specific operations that a particular process can perform.
Typically, the system handles requests for permissions by automatically allowing or disallowing the requests on one of two bases: certificates, which the developers sign an app with and hold the key to; or by prompting the user.
We're Leaving It All Up to You
Google's remote removal of these applications comes on the heels of recent claims regarding security issued by research firm SMobile based on its study of about 49,000 Android apps. SMobile said its research found, among other things, that 20 percent of apps studied ask to access private or sensitive information belonging to the device's owner; five percent can place a call to any number without interacting with, or getting permission from, the device owner; and 383 apps could read or use the authentication credentials from another service or application.
"The SMobile report did not claim that the apps had security holes," Google's Nancarrow pointed out. "It said that the applications were granted permissions that could be used for malicious purposes, but, as our statement on the matter indicated, all such permissions are granted explicitly by the user through clear dialogs at the time of download."
Android's Maginot Line
Android's inclusion of user prompts as part of its security model is dangerous, Randy Abrams, director of technical education at ESET, told LinuxInsider. Users who are not savvy will be particularly at risk.
"The Android sandboxing appears to be quite easy to defeat with simple social engineering," Abrams pointed out. "If a user thinks that following the directions to allow inappropriate permissions in exchange for porn or free games will get him those, the application will be given every permission it requests. This isn't a failure of operating system security; it's an operating system doing what it's supposed to do and a user making ignorant choices.
"I would expect that, by this time in 2012, we will see Android devices attacked the most successfully, and Windows Mobile and Apple showing no significant differences in exploited security issues," Abrams predicted.
Is It All in the Timing?
"That Google announcement was a public relations and marketing move," continued ESET's Abrams. "As there was no published security risk associated with these two applications, the remote removal was really not about security at all and probably should not have been done," he said.
"Google hopes that publicizing the remote kill ability will make users forget how simple it is to distribute potentially malicious applications for Android-based devices," Abrams remarked.
"This announcement was intended to highlight a feature of the Android security model and explain an action we had taken," Google's Nancarrow countered. "It was unrelated to the SMobile report."