Permissions Bug • September 7th, 2010

By: Brenton

There’s been a lot of reports of trojan Android applications in the market over the last few weeks. Because of which, I’m falling victim to the resulting fallout of user paranoia.

In a recent comment on my application in the Android Market, Tony states:

“This download page only indicates that the app uses System Tools, but the Applications menu says it requires access to make phone calls. Uninstalled.”

Now, Tony got some things wrong in his comment, but he got some things right too; which I found very alarming.

What Tony Got Wrong.

Tony stated that my application requires access to make phone calls. This is not true. The only permission my application in the market requests, is the ability to prevent the phone from going into its sleeping state.

I do this so my flash light will stay lit until you expressly turn it off. This way, you can launch my app and set the phone down to light a room while you perform a task. Or, to stop the need to continuously futz with the screen to keep it on for those with shorter sleep times.

What Tony Got Right.

Tony found additional permissions which he didn’t grant being displayed in the Settings > Applications > FlashLight > Permissions section. As you can see in the image below.

Different permissions shown after installing application.

This had me perplexed. Why would my application suddenly have these extra permissions which were not requested?

What I Believe Is Happening (Updated).

Because, I allow the user to move my application to the SD card, it automatically grants these extra permissions.

“Modify/delete SD card contents,” would be needed in order for the application to write and remove itself from the SD card as it’s moved back and forth.

“Read phone state and identity,” would be needed in order to make sure that the SD card is in the same phone that put the application there.

Looks like access to the SD card and phone identity was always allowed in versions of android 1.5 and earlier. So, if you create an application that is compatible with these legacy devices, you automatically gain access to these permissions. If you want to make sure you DON’T have these permissions, you have to expressly state that your application targets a later version of Android.

<uses-sdk android:minSdkVersion=”3″ android:targetSdkVersion=”4″/>

This is a wee bit scary. It’s feasible that a user thinks they’re only granting an Internet permission, but in reality the app could have complete access to their phone identity and SD card data which could be transmitted.

File It As A Bug.

There’s no question in my mind that this is a bug. Even if this is happening by function, it’s inadvertently eroding the user’s trust. Only permissions expressly granted by the user for the application should be shown under the system information. You can view my bug filing here (star it if you’d like Google to address it.):

Food For Thought (Updated).

If I’m gaining storage permission in this way, could I write an application that secretly or maliciously augments SD card data without the users knowledge?

Update: So, I just tested this and frightening enough it works flawlessly! I created an application called “Permissions Test.” All the application does is look for a file on the user’s SD card called “deleteme.txt,” and remove it if it finds it. I then submitted it to the market only requesting the Wakelock permission. Sure enough, the Android market only notifies me of that single permission, but allows me access to the SD card anyway and deletes the file. I have removed the app from the market since I don’t want anyone to download it.

  1. [...] to Comments (RSS) « Permissions Bug Back On-line [...]

Leave a Comment