The security of Google Android has once again been called into question after an academic researcher discovered 12 malicious apps hosted in the operating system's official applications market, some that had been hosted there for months and racked up hundreds of thousands of downloads.
Ten of the apps reported last week by North …

COMMENTS

"Angry Birds Rio Unlock" sounds like a legitimate program?

[Appname] Unlock isn't unusual

Various people who provide free and paid-for versions of their android applications have a lightweight unlocker, presumably so that the free version would not need to be removed on upgrade and any data associated with it would remain in place.

Not difficult to see who the publisher/author is and spot that there's an issue, but 'unobservant, don't care about technology' has always been the ideal target market for malware authors.

Numpties

While I had the same thought as you, the tech-illiterate who have picked up an Android consumer-focussed phone are likely to perceive anything in the market as being legitimate by the very fact that Google "owns" the market.

Perhaps Google need to add a rewards scheme for security firms identifying malicious apps in the market? That way, they don't need to expend any effort themselves, if that's their issue here.

@ Ru

True.. however typically the name of the company for both the app and the unlock would be the same. If I see an unlock app anywhere that was not created by the publisher of the original app I would be highly suspect.

Android OS nupdates

"Add to all of this Google's own admission that more than 90 percent of Android users are running older versions of the mobile operating system that contain serious kernel vulnerabilities."

Over here in Thailand, I was on the verge of buying a Desire HD running 2.2 last year when, on a whim, I asked the assistant whether it would be updatable to the latest version of Android. I'd heard this happened over the air, and was curious as to how it might be implemented in this country. They smiled shyly, and said "No, you cannot". I asked if this is dependent on the network operator, or the handset itself. "No". I asked if you can download the update package and install it yourself via a cable. "No." Apparently, android devices sold in major shopping centers here simply cannot be updated. This was Fortune Town, a pretty respectable place, more so than Pantip Plaza, MBK, or some of the more shady IT dens around town.

I've since bought a Nexus S from the UK, brought it over here, and it updated OTA to 2.3.4 quite happily without me pulling any magic strings or doing a manual update.

I'm left wondering what the hell the assistant was talking about, and whether their devices really would have locked me at the old kernel version. Android has performed wonderfully for me, but sadly the FUD (some real, some imaginary) surrounding the OS is worrying.

Updates...not as simple as that...

It depends on the device. The Nexus S is a Google sponsored phone, running stock Android which is aimed at developers mainly, so the updates come straight from Google and it should always have the latest version of Android. The Nexus One is the same.

With devices like the HTC Desire, Desire HD, Samsung Galaxy S, <insert random Android device here>, the updates come from the manufacturer, not Google. The manufacturers are not forced to update the devices, so many devices end up being either abandoned, or don't receive updates in a timely manner and end up being stuck on an old, insecure version.

I expect most of it is down to commercial reasons, why should manufacturers update their existing devices when you can force people to upgrade by abandoning them.

Take the HTC Desire for example, it's been 6 months now since the Android 2.3 (Gingerbread) source was made public, and HTC still have not released a 2.3 update for the Desire, and HTC get the source *long* before it is made public.

There are 2 ways you can ensure you will always have the latest, most secure version of Android. Buy a device sponsored by Google, such as the Nexus S.

Or...do what I do, root your device and build your own ROM from the latest Android source, it's not *that* hard to do.

It would be updateable

HTC have provided OTA updates in the past so saying it's not updateable is rubbish. It would be more correct to say that phone devices are reliant on the manufacturer supporting their products and some are better than others in this regard. Apparently Motorola and Sony Ericsson stink for their after sales support. HTC is one of the better provides and indeed the Desire HD got a 2.3 update last month. The best support of all would be Google branded phones which tend to track new releases pretty sharpish.

Failing decent support you can often update via other means such as CyanogenMod.

It's down to the carriers and handset makers

Both have the ability to modify the OS after google have finished with it. Perhaps the Thai carriers added language support for the Thai alphabet? At any rate if they made any substantial changes then they would need to supply the OS updates, and this is why most android handsets can't be upgraded without being jail-broken.

Apple's model is that they supply iOS and carriers have no say in what is on the phone. They still need to produce slightly different versions of iOS for different devices, but they have a relatively small number of models so it's easy for them to issue simultaneous or near simultaneous updates. OEMs.

My grey import Desire HD upgraded to 2.3 just fine

I actually have a Thai HTC Desire HD because that's what simplyelectronics.co.uk shipped me when I ordered one in the UK (I must admit I wasn't very happy when I realised I'd been sold a grey import, but that's another story).

HTC released the 2.3 upgrade for the European region last month, the Thai one was about 3 weeks behind. It arrived last week and installed without problem. So it's not true that they can't be upgraded here but you do have to wait for HTC to issue the upgrade for the phone's original region.

Re: Updates...not as simple as that...

Its not quite as simple as that afaik. The manufacturer has to release the update for the phone, but then the network operator is the one that deploys it - and they only do so after "testing compatibility" with their bloatware.

So Google release the update. Manufacturer (sometimes) releases it after that. Network operator (sometimes) finally releases it to the phone owner - often many many months after the original google update.

You can get around some of these problems by rooting the phone and updating yourself - be its certainly not a straightforward process.

Thai Friendly

Out of interest, the stock OS delivered from the UK and updated OTA both render Thai fonts beautifully with no tweaks necessary by me. This doesn't help me comprehend the language, but it's perfectly legible :)

I agree I missed the point about my Nexus S being a far more advantageous choice than the Desire range in terms of updates. I do wonder _how_ it got to my phone. I have no data plan, no 3g, but do have wifi in the home.. the update just arrived, and I can't actually tell if it came in from somewhere in Thailand or a server abroad, from the local network operator or Google, via wifi or other comms method.. Ah well, best not look a gift horse in the mouth :) Someone recommend I check out XDA and their 'amazing' custom ROMs, but I simply see no need at present. Same for rooting.

although Jiang didn't find any evidence they were actively used.

but in the paragraph above..

Ten of the apps reported last week by North Carolina State University professor Xuxian Jiang contained highly stealthy code that collected users' browsing history, bookmarks, and device information and sent them to servers under the control of the attackers

Either you need to read more carefully or you think "Privacy is for people with something to hide"...

Absence of evidence != evidence of absence

Occam's razor

Vetting applications

"Google makes no promises to vet the security of apps hosted in its own store" because that is impossible. Apple can't do it for the apps hosted on their market, either - Google is simply being more honest about it.

It is possible to design a program in such a way, that it will start performing malicious actions after receiving an external signal and no amount of testing will be able to reveal that it is capable of doing so. Even careful reverse-engineering of the program will only reveal an encrypted area which the program itself has no means of decrypting. The idea is not even new - it was conceived in 1998 and there are even some viruses for the PC that implement it (albeit poorly). Search for "clueless agents" to, uhm, get a clue.

True, execution of decrypted code is more difficult to implement in Java, especially with code signing, than it is in assembly language - but combining that idea with the "interpreter" idea mentioned in the article makes it perfectly possible.

"Data execution prevention" = no encrypted executable code?

But I don't know if it applies to Java - or to strongly Java-flavoured Dalvik.

Also, it isn't clear to me that the program wi!hich installs with access only to a limited set of Android features, gets to go on to breach those restrictions, such as sending expensive text messages. Although that is the sort of thing that happens. Also, are people carefully checking the permissions on each app? To do that, you have to understand the questions!

first approximations first...

Agreed, no-one can offer a guarantee of a negative (there is no malware in this application).

A delayed-action payload can be detected using code-matching from known malware predecessors, the standard AV approach, or from heuristics, broader but similar.

The point is that any form of scanning is redundant if the item being scanned can be switched for another later. Therefore, Google need immediately to constrain code updates to their marketplace, where the apps can be scanned, or to mandate code signing where only scanned code gets a signature, or both.

Granted there will always be ways round anything, but the basic protections are not implemented at present - lets get these fixed first.

The encryption methods you mention should be stopped by isolation of code and data, forgive me but I'm not sure to what extent Java manages to avoid all the execution-of-data type exploits.

this is ordinary people we're talking about?

Most Android users have little idea about these permissions and they do need a good level of technical knowledge in order to interpret them. So their eyes just glaze over and just tap on the OK button...

They do this with Windows and its hordes of malware, so why would their behavior alter on Android?

The inability to update Android devices

Updates should be part of the Android/Google agreement

Personally, I thing if you buy a Google approved phone, i.e. one that comes with the Market place and other Google apps, there should be something in the agreement between the phone maker and Google to garantee updates for a period of time.

i.e. a phone manufacture:

* Must provide all Android OS updates for up to 24 months after the launch date of the phone (as long as the hardware can cope with the update of course), and...

* Must provide those updates OTA and within 1 month of the update being release by Google themselves.

If they don't agree to this, then they should not allowed to have access to the Google Market etc.

Improve but not fix

"the Google spokesman responded: "Code signing, as discussed in various public forums, does not guarantee that a malicious application cannot run untrusted code. Regardless of the platform, it doesn't prevent an application from executing code from the Internet.""

But surely closing 1 stable door might keep a few of the horses in... as the security experts have attested later.

Also the update problems are not limited to Thailand or the fault of Google; my T-Mobile G2 (an HTC-Hero with a new loading screen) took months to get the 2.1 updated HTC issued for it and I am still waiting on any news about if or when the Peep fixing update might make it's way through T-Mobile UK. It is not a bad thing that Google have let the OS be a bit more adaptable and less centralised to their control but it does mean they can take some flack when handsets cannot update for whatever reason. I might have to root it and stick on a 3rd party build; but I do like the HTC interface changes so it would be a shame.

@Android OS nupdates

Gasp! FOSS is inherently vulnerable...

Because anyone who actually understands human readable code can examine it, and experiment, until they find vulnerabilities. It is definitely trickier, although not impossible, to subvert systems without the source code. Could this be why Google still hasn't opened up the source for Gingerbread?

As a solution, how about Android Pro that is open source and hackable, install-anything, for nerdy types who accept all the risks, and a consumer version of Android that is more Apple-like and locked down for users who are happy with the functionality on offer, and only get access to vetted apps?

Google could even charge manufacturers for the consumer version, with secure access to the vetted appstore, because that kind of ecosystem takes money to run effectively. Android Pro sounds so manly, the nerds might even go for it, as it shows off their l33t status to their mates(s).

Re: Gasp! FOSS is inherently vulnerable...

"Because anyone who actually understands human readable code can examine it, and experiment, until they find vulnerabilities. It is definitely trickier, although not impossible, to subvert systems without the source code."

You're very close to advocating security through obscurity. That didn't help various smartcard vendors with their "special algorithms", so I doubt it'll help smartphone vendors.

"Could this be why Google still hasn't opened up the source for Gingerbread?"

There were a few facepalm moments with previous Android versions, so it's possible, although it's more likely that they can't be bothered to engage with the community and want to retain a special press conference (or Steve Jobs "one more thing" moment) allure for everyone who still gets off on that kind of thing.

"As a solution, how about Android Pro that is open source and hackable, install-anything, for nerdy types who accept all the risks, and a consumer version of Android that is more Apple-like and locked down for users who are happy with the functionality on offer, and only get access to vetted apps?"

Don't we have that now? Operators and vendors getting in the way of people wanting to just install what they want and get on with it. All these butch-voiced "you are not allowed to do this, consumer" code-signing and lock-down antics are just afterthoughts on the matter of security.

Everyone should be reading up on actual security architectures, like the one they were developing for the OLPC, for example.

Right, as a non programmer....

As i understand Android is made/owned/written/supported etc by Google?

I would think that all apps put for submission have to pass some basic tests?? You know, to see what it does, if it crashes, if its a virus etc...

I would also like to think that google can reverse engineer (de-compile?) the submitted exe back to hex/ascii/c++/CPM/Forth/Fortran/python/Sinclair B.A.S.I.C or whatever and then be able to spot dodgy practices like these..Its for their own OS ffs...Why is this shit slipping past the net???

Re: your black/white world

It's harder than you might think.

There are viruses out there that detect when they are running under surveillance (a virtual machine or a debugger) and "act innocent" under those circumstances. So you decide to decompile (as best as can be done) the app and search for "suspicious" code. What does that look like, exactly? Network access? Storage access? Asking for a password to access personal data? If you start banning apps that do these things, your end-user is going to conclude that your device can't do very much and s/he should have bought the Apple instead.

In fact, given the utterly shit nature of much of what passes for "legitimate code", I rather suspect that the task is impossible even for someone of above average human intelligence, let alone a machine.

Dodgy looking apps...

I'm wondering if anybody's taken a good look at the multitude of 'free music' apps that are all over the Android app store. Yes, they're obviously a bit dodgy in the first place but all of them want permission to access virtually everything on the phone, when surely all they should need to function is web access and the ability to write files to the SD card.

OK, more fool you if you download one, but they're consistently in the most popular apps lists on AppBrain etc. so lots of people have. I'd like to know what they're up to.

Source upload?

If google dont want to police their appstore, why dont they force devs to upload Source and auto vet the code looking for functionality that can be red flagged for review, could even be peer review. This way google put the minimum effort into the vetting process and the source can be compiled on upload so it doesnt exist on the servers (Obv google would take a copy :P )

Source code only...

Should be submitted to the Android apps store for peer review and compiled by them only after being checked thoroughly.

Authors of the code need to be identified (and verified) by name and not via some anonymous hushmail or Paypal account.

If you do not want to submit source code then an insurance policy should be pre-payed by the submitter to cover $$$ losses in case of malicious code being introduced. That policy should also have a heavy deductible to penalize the authors to minimize any financial gain realized by the errant code.

The fix is pretty simple

...and has been an outstanding request on the Android Issues site for years: We need to be able to fake permissions.

That is, when some application asks for permission to send SMS we currently have a boolean choice: refuse, and do without the app; allow, and hope it doesn’t bankrupt you.

What has been suggested (many times) is there should be a third choice – safe mode. The app *thinks* it has permission to send SMS messages (for example), but they don’t go anywhere.

An app that wants to read your contacts would, if that permission were ‘safe’, get an empty list. One that wanted to access the internet would get a 404. One that tried to use the camera would get a black rectangle, etc.

There’s no good reason for not having such a system – claiming that users are too dim to understand it is no excuse for exposing them to the vulnerability otherwise and force on them the impossible question of “the App wants these permissions, do you want to install it?”.

We’re in the ridiculous situation of some developers listing what they require permissions for – which just changes the question from “do I trust the app?” to the rather more realistic “so I trust the developer?”.

‘Safe mode’ is the obvious solution. (Choose ‘safe’ when installing an App and all permissions are set to safe mode, one can then elevate individual permissions for an App under the Manage Applications setting screen).

I like the idea

Perhaps rather then sending all SMS messages to /dev/null you could also have a popup show you the message is being sent and ask for permission to send it. A similar thing for accessing the contact list wouldn't really be logical, but I'm not sure how many apps could actually have a good reason for doing that.