Home
BYTE Newsletter
Keep up with all the BYTE News and Reviews

Subscribe
Larry Seltzer

Larry Seltzer



Wanted: Secure Android App Whitelisting

Comments | Larry Seltzer, BYTE | February 28, 2012 08:00 AM

Category: Tablets, Smartphones

If you are an Android user, you've noticed that when you install an app you are presented with a list of permissions. The idea is that you can decide whether you trust the app to have these permissions. In fact, these screens are like Terms of Service agreements for software: They're important, but everybody just clicks OK and puts them out of mind.

More Insights

Webcasts

More >>

White Papers

More >>

Reports

More >>

Android asks too much of its users in terms of security. (Apple's iOS, on the other hand, asks too little, but that's another story.) Even if you think users should pay attention rather than just blindly clicking, Android permissions are too complicated. The end result is that a malicious app could request excessive permissions, and very few users would notice.

And the Android platform may not even be as secure as it should be. Researchers at North Carolina State University found vulnerabilities in preinstalled software in eight handsets from HTC, Motorola, Samsung, and Google that would allow significant eavesdropping and data theft.

Also, it turns out that for all versions of Android prior to 4.0 (Ice Cream Sandwich), the OS automatically assigns the permissions WRITE_EXTERNAL_STORAGE and READ_PHONE_STATE. WRITE_EXTERNAL_STORAGE is pretty clear and generally refers to the SD card. READ_PHONE_STATE is one of three values: IDLE, RINGING, and OFFHOOK. Are these a big deal? Give me some time and I'm sure I'll come up with a way to abuse the privilege.

The best solutions for situations such as these is a controversial topic, but I've long been a fan of whitelisting, under which users would be able to install only apps that are on a special pre-cleared list. Apple already does this with its App Store. Theoretically, there are problems with it, but in the real world it has proven to be a powerful technique. I think it's fair to say that if you install arbitrary apps from the App Store, you might get ripped off, but you aren't going to get "exploited" in the computer security sense.

There's at least one way for Android to implement this now. 3LM provides Android security and management solutions that fill in the many gaps in Google's implementations (Read about some here.). 3LM's big news, announced at RSA and Mobile World Congress, is its partnership with NQ Mobile to provide user-facing anti-malware protection. NQ Mobile is big in the Android anti-malware business, but primarily in Asia, where Android app stores other than the Google Android Market are popular.

Much more interesting from my point of view is the way 3LM extends the Android security system to give IT or a carrier better control. The company's software adds security hooks that protect APIs so that only whitelisted apps can use them. Alternatively, you can blacklist specific developer signatures and/or applications. They need to partner with OEMs to do this, though, because Android is at least secure enough not to permit end-user installation of software allowing this sort of capability.

The same security extensions allow 3LM to make Android anti-malware more powerful; under a stock Android installation, anti-malware is so unprivileged that it can do little more than alert the user that it's too late--they've already been compromised. 3LM allows such attacks to be prevented.

Personally, if I were managing an IT department that allowed Android phones, I'd want this capability, and I'd be strict with it: You want to install an app on a company phone? We have to approve it first. If it's not approved, you'll have to wait.

Some argue that this is a losing battle and the defensive lines need to be drawn further back, at the permission or API level. Either way, the 3LM approach has you covered. Just don't settle for out-of-the-box Android security.

Follow Larry Seltzer and BYTE on Twitter, Facebook, LinkedIn, and Google+:



Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

BYTE encourages readers to engage in spirited, healthy debate, including taking us to task. However, BYTE moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. BYTE further reserves the right to disable the profile of any commenter participating in said activities.

COMMENTS

Tune In to BYTE
Facebook Twitter LinkedIn Newsletter RSS
Whitepapers
whitepaper
In this paper you will learn the five trends shaping the future of enterprise mobility. Learn how the rise of social media as a business application, the lurring between work and home, the emergence of new mobile devices, the demand for tech savvy employees and changing expectations of corporate IT will fundamentally change the workplace.
whitepaper
In a survey of more than 1,700 information workers (iWorkers) in North America, notebooks, desktops, and smartphones were found to be “must-have” devices, while tablets, slates, and netbooks were relegated to “nice-to-have” status, according to a commissioned study conducted by Forrester Consulting on behalf of Dell and Intel.
Sponsored by: Dell
Upcoming Events