By Joe Levi | June 30, 2010 6:30 AM
Reader Morgan Gillespie commented on my recent article detailing how Google can remotely uninstall apps from your Android phone — and recently has. The REMOVE_ASSET intent does just what it sounds like: when triggered, it removes the associated asset (more on that in a minute).
In his comment, Morgan makes some very valid points. “Thus far, Google has used this feature to only protect its users for an app that was designed solely to mislead the user and to obtain user/device information. … Google’s approach is certain okay thus far, I realize many people see this as a ‘slippery slope’ however I do not see Google as one that is sliding. They put their stake in the mud, it is to protect their users and that is it.”
And Morgan is absolutely correct: Google has only done this once, and it was with the application developer’s “permission”. Morgan and I disagree only in that I feel Google’s mechanism should be to “nag” the user to allow the uninstall, whereas Morgan believes the forced removal of a “malicious app” is fair game if the app is malicious and data loss, data theft, or damage is imminent. Removal of “non-dangerous” apps, he says should be optional. I’m inclined to agree.
Based on Morgan’s comments I decided to dig a bit deeper to see exactly how this was accomplished, and by what process the removal programmatically takes place. Clove Technology pointed me in the the right direction. You’ll be shocked at what I discovered.
Based on their information, I went right to the horses mouth. The developer of the questionable apps is Jon Oberheide. Why did he write these two “useless” and “misleading” apps? He published them to discover exactly how Google handles app installation and removal — and that he did.
According to his article Google uses the GTalkService Connection to perform not only remote uninstalls, but Market installs as well. “Your Android device maintains a persistent TCP/SSL/XMPP connection to Google’s GTalk servers at all times over your device’s data connection (either your mobile data service or WiFi). This connection is managed by a service aptly named GTalkService. Your device will automatically re-establish this persistent connection whenever you move between networks and periodically sends heartbeat messages to Google’s servers.”
It’s what enables Google to perform push-notifications to your phone so that it doesn’t have to “phone home” to check each email, Facebook, Twitter, or other account that you have every pre-determined amount of time. Instead, data can be pushed to Google, then sent to your phone as it happens via the GTalkService. With Froyo, this service has been put on steroids and new “intents” have been added to the Android API to handle events that are delivered via the GTalkService.
That’s pretty cool (potentially dangerous, but still cool). But what wasn’t expected was that regular app installations from the Market use an “intent” that is the mirror image of the REMOVE_ASSET intent: the INSTALL_ASSET intent.
Just as you’d expect, this “intent” tells the Android OS to install the specified .APK.
Jon concludes, “While remotely removing apps might ruffle the feathers of people who like the feeling of having full control over their device, the remote install functionality is of more concern from a security perspective … if an attacker is able to MITM this SSL GTalkService connection for a particular device, it may be possible to spoof these INSTALL_ASSET messages to deliver a malicious application payload. If Google’s GTalkService servers were compromised, the malicious impact would obviously be a bit more widespread.”
Call me naive, but wouldn’t taking this low-level control away from the OS and instead forcing end-user interaction (approval or disapproval) in both INSTALL_ASSET and REMOVE_ASSET scenarios potentially resolve both these issues?