Researchers at German security firm Curesec have identified bugs present in most versions of Android that can allow malicious applications to place phone calls, even when they lack the necessary permissions.
By exploiting these vulnerabilities, rogue apps can get up to such mischief as surreptitiously dialing out to expensive …

Re: So

Kit Kat 4.4.4 was released before this was announced and was released in days after 4.4.3 so if you were concerned about getting quick updates you could have bought a Nexus device or a GPE device (still lots of choice) or just not downloaded apps from dodgy Warez stores.

The thing is you have plenty of choice with Android, with Apple you only have two (take it or leave it - oh sorry, you can take it or leave it in 'pretty' colours as well).

Re: "The fix is to get upgraded to version 4.4.4"

They fixed a metric assload of security holes in KitKat 4.4.3 running on my Moto G, including ones that used to let me turn the cell data & GPS on/off via code. It became difficult to tell my Raspberry Pi to open the garage door when I get within 70 meters of home.

That's ok, my phone's rooted so I just made my app a "system" app, but that's now harder to do in KitKat too.

I guess security is now sorta-kinda on Google's radar.

And I hear 4.4.4 is coming to the Moto G in a couple months, so I'm glad I don't have to throw it away and buy a new phone.

Re: Runnng 4.4.4 no worries

Agreed - the problem here isn't Google / Android - they fix the bugs pretty much as soon as found (and all software has bugs, regardless of who makes it).

The problem is Samsung/LG/HTC along with Vodafone/EE/whoever, who require that so much extra crap is added on top of Android, and this all needs to be rewritten and thoroughly tested for a new release. This is what takes the time to roll out, and why they all can't be bothered to upgrade old handsets. Hopefully the Silver programme may change this mindset.

Re: Runnng 4.4.4 no worries

all software has bugs, regardless of who makes it

True. That said, I took a look at the second bug (since I'm running a phone with Android 2.mumble, though I install almost no apps on it, and certainly not without considerable scrutiny), and it's 1) a dumb mistake on the part of the developer, 2) pretty obvious when you have the source code, 3) part of a general class which is likely to contain other bugs of the same sort, and 4) indicative of a systemic software-security failure on Google's part.

The last is the failure to recognize that security is a cross-cutting aspect, and mechanisms such as Android's "activities" either need security implemented at a lower level (say, using a capability architecture of some sort), or need it automatically injected via some aspect mechanism. Requiring the developer to either review which activities are exported, or to manually implement safeguards against misuse, will inevitably produce privilege-escalation bugs.

Explicitly wrapping security around functionality is good - it reduces the attack surface and increases the depth of defenses - but in itself is not sufficient against reasonable threat models for consumer software that controls anything of value.