The CommonsBlog


Servers Are Risky. Mobile Servers Are Riskier

The folk over at xda-developers are doing excellent detective work on various bits of crap that get pre-installed on devices. Right now the major crisis is that some HTC devices have an actual daemon, listening on a port, that will happily cough up all sorts of private data to anyone on the device who asks. This post over at the xda-developers site explains the gory details, such as they are presently known.

Lots of other people are covering the “WTF HTC?” angle on this. I’d like to point out how this is a fine example of why server daemons on mobile devices are scary.

Unless you’ve been living under a rock for the past decade or so, you are well aware that Web servers, mail servers, and their brethren get attacked all the time. That’s why there are clear guidelines for how to harden such equipment, from firewalls to minimizing the number of daemons listening on ports in the first place.

Mobile devices generally do not have firewalls. More importantly, users are installing apps on these devices, and those apps would be inside the firewall anyway. Any app can get at any server socket you happen to open, and if somebody can spoof your protocol, your code will do the app’s bidding.

While the HTC daemon is at the firmware level, it is entirely possible to create such daemons at the SDK level. ServerSocket works, and if you set up an everlasting service (perhaps using startForeground()), you can listen on whatever port you want to.

For example, back when SL4A was the Android Scripting Environment (ASE), it used an embedded Web service to enable Python and other scripting languages to invoke Android-specific logic. Initially, though, the Web service would respond to any request, and since that service would serve up details like location data, it was leaking private information. Around the time the project shifted names, they locked down this Web service using a token-based mechanism, so only authorized clients (i.e., the user’s chosen scripts) would be able to get data out of the Web service.

If you are determined to implement some sort of socket daemon on Android, you need to make sure that you are properly defending against rogue clients — including ones not on the device, if you’re actually binding to a real IP address instead of localhost. And, if you have not yet decided whether or not to implement such a daemon, perhaps the HTC lesson will be useful to you, and we can have a silver lining for this exceptionally dark cloud.


Stuck on an Android problem? Subscribers have access to live office hours chats with Mark Murphy, to help you work through your challenges!