I was troubled by some comments to a recent article of mine. It was about Android and how a certain security app was able to manipulate it. I double, even triple-check questionable sources. The thought of possibly provided inaccurate information scared every known demon out of me.
I only double-checked this source, so best get a third opinion. Since the information dealt with an Android app, I enlisted–once again–the help of fellow TechRepublic writer and experienced app developer, William J. Francis.
I called William and asked if I goofed by stating an app can remotely turn on various features of an Android-based smartphone without having permission. The conversation that ensued ended with more questions than answers. Not a good sign.
We determined to do more checking and get back together. We did, the next day, sharing what we learned about the issue. Now, we’d like to pass that information to you. William is the obvious expert, so I decided to do what I do best–ask questions.
Kassner: If Android is designed to prevent applications from taking this kind of liberty with device hardware, how are app developers getting around this?
Francis: The software must be exploiting a security hole in the operating system. For example, the vulnerability built into the Power Control widget. After doing research, I managed to replicate the behavior. As further proof, I developed an app to check phones for this vulnerability. Here’s how the exploit works.
When a user buys a smart phone, it comes with an operating system and a set of core applications installed. These “read-only” applications from the manufacturer are considered “safe”. Therefore, restrictions given to programs installed by the user, do not apply to the core OS and “read-only” apps. In fact, core software components have elevated privileges, as they should–for the phone to function properly.
The problem arises when a core component exposes an interface that can be called by other software. Developers that are aware of this, write programs leveraging the exposed interface of the pre-installed application to turn on a feature they want to use, but do not have permission to.
Kassner: So, there are controls in place. But they’re being sidestepped, right?
Francis: I can’t say with certainty how any specific app in the market place operates under the hood, but, I was able to exploit one of these security holes in my testing and I think it’s reasonable to assume other developers are taking advantage of this sort of approach.
Interestingly, this sort of thing is not specific to Android. We see this same shortcoming on other smart phones and desktop operating systems. What is specific to Android, and makes this issue particularly nasty, is the time frame required to get fixes to the vulnerable devices.
When Windows 7 has an issue, Microsoft writes a patch and pushes it directly to their customers. When a security flaw in Android is discovered, Google or someone in the open-source community submits a fix, the patch is reviewed, and a new release is finally made.
However, that release does not get pushed from Google to the user’s device. Instead, the release gets sent to the handset manufacturers, and finally to the phone carriers. If no party vetoes the patch along the way, the fix finally gets to the customers.
This process can take months. And, it’s possible the revisions never become available for a particular phone, as both the handset manufacturer and the carrier have little incentive for doing so.
Kassner: What danger does this exploit present to a user?
Francis: This particular exploit has a whole range of potentially-damaging fallout. My testing shows that beside GPS, an application if so constructed could control Wi-Fi, Bluetooth, and the phone’s LCD backlight.
In an obvious attack scenario, a rogue application could drain the phone’s battery in a few hours. In a calculated attack, a malicious app could track a user’s whereabouts, possibly for days or week–without the user’s knowledge or consent.
It’s also worth pointing out that a resourceful developer could use this exploit for the user’s benefit. And, many app developers are doing so. Whether they are using the same exploit I am or a different technique; they are using their knowledge in a responsible and benevolent manner that adds value to the user experience.
Unfortunately, as a smartphone owner myself, I think it’s too risky to rely on the good intentions of every programmer.
Kassner: Are all phones susceptible to this take-over?
Francis: They are not. And, it’s tough to say how many phones are at risk. The reason is two-fold. First, not all versions of the Android operating system include the component which exposes this particular security hole.
Second, handset manufacturers as well as carriers often exercise their right to customize Android before releasing a phone. This customization often includes removal of “read only” applications in order to replace them with manufacturer/carrier specific versions.
It’s hard to put a firm number on the amount of susceptible phones. If pressed, I’d speculate there are more vulnerable phones than not, based on information from Google. If you want to be sure about your device, I recommend installing the free application I created and check for yourself.
R U @ RISK?
I had to know. So I installed R U @ RISK?, paying close attention to the permissions. As you can see, no permissions were asked for.
Once R U @ RISK? loaded, I scanned the app for malware. I wanted to make sure William wasn’t messing with me. Next, I nervously opened R U @ RISK and hit the “Check Now” button. Thankfully, my phone appeared to be safe.
The next phone I tested was not.
For us “prove it to me” types, William added the ability to “See for yourself!” I punched the “Turn on GPS” button and a cute antenna appeared. Hmm. Is it really turned on, though?
Sure enough. The pull-down clearly showed that GPS was enabled.
Still not satisfied–I’m a tough sell. Besides, the Power Control widget contains the security flaw. So I started GPS Test, a nifty app that produces all sorts of information. The GPS was indeed active.
What does this mean?
There are two findings we need to consider:
- Valid apps with appropriate permission are able to turn on features such as GPS without asking the user.
- Applications so constructed can turn on features without permission and do not require user intervention.
Matters are even more complicated. R U @ RISK? leverages the Power Control widget flaw. So William only tests that. He wanted me to stress it is possible that certain phones could pass his test, but still be vulnerable. Why? A developer may have found another weak link into Android. Or the version of Android on that particular phone works differently.
I profess to be paranoid, almost to a fault. Remember, I didn’t trust William. Yet, I was hoping I didn’t have to worry about whether my phone is listening to or locating me without my knowledge.
Is it time to put hard switches back into phones?
Update: My son and most ardent critic said I messed up. It would have been more impressive if the GPS receiver activated upon opening R U @ RISK?. That sounded interesting and William said it is entirely possible. But, we decided not to. The reason: If the app was mistakenly left active, the phone’s battery would drain in short order. Not something we want responsibility for.