Stagefright Vulnerability in Android Phones

The Stagefright vulnerability for Android phones is a bad one. It’s exploitable via a text message (details depend on auto downloading of the particular phone), it runs at an elevated privilege (again, the severity depends on the particular phone—on some phones it’s full privilege), and it’s trivial to weaponize. Imagine a worm that infects a phone and then immediately sends a copy of itself to everyone on that phone’s contact list.

The worst part of this is that it’s an Android exploit, so most phones won’t be patched anytime soon—if ever. (The people who discovered the bug alerted Google in April. Google has sent patches to its phone manufacturer partners, but most of them have not sent the patch to Android phone users.)

Posted on July 28, 2015 at 6:37 AM57 Comments


Thoth July 28, 2015 6:57 AM

Android OS itself contains millions of lines of codes and some of them are proprietary to the vendors themselves. If the TCB is more than 10K ~ 20K lines of codes, it is not easy to audit. Since the first day of Android’s inception, the LOCs have been inspected by so many people and yet so many bugs escape notice and Android is literally the Windows for phone being full of bugs and holes due to it’s huge codebase.

If Google wants Android to be secure, they should sit down and re-think the entire Android system which will be highly unlikely due to the huge (and immobile) setup and investments. Android’s fate is doomed to be like Windows by being so bloated and popular.

The only saving grace is to be daring to re-think Android and create a 10K LOC TCB microkernel by Google and verified widely by known security research labs. A mathematically rigid microkernel TCB that is easily verifiable, open and tiny will be needed. Genode and KSyslabs have done good research in this area and have gotten a TCB for Samsung phone (certain type) and ARM chips down (Fiasco.OC TCB + L4Android Userland). If Google can leverage and fund these researches and incorporate into future releases, it might help lessen vulnerabilities and hidden bugs.

Samsung via it’s KNOX (INTEGRITY HILL on the Secure World side as the OS ?) and Apple via it’s Secure Enclave (using a modified L4 on the Secure World side) has made progress in hardware, OS and software security but it needs more testing on the KNOX and Secure Enclave but these can be hard due to their proprietary nature.

Fall back to the Genode and Ksyslabs TCB I guess ?

Alastair McKinstry July 28, 2015 7:29 AM


Care to explain why the answer is a new TCB from Google if the problem is that phone manufacturers won’t send out patches?

What about this particular bug would be stopped by such technology?

If the userspace is overly-permissive and insecure then a secure kernel won’t help. You still need to patch bugs when you find them. In practice, other ROM suppliers like CyanogenMod have already patched this.

If a “secure locked down’ ROM means no security process is in place to patch bugs, then its possibly a step backwards, not forwards.

We need to get phone manufacturers to take security issues seriously. Boycott or even ban phones that don’t have an update process in place.

Kyle Rose July 28, 2015 7:34 AM

Maybe what the Android ecosystem really needs is a worm like this that takes down the cell networks with an unstoppable flood of traffic: maybe that would convince the carriers to update phone software much more frequently and not to abandon year-old phones only a short while into their life cycle.

Dan Benton July 28, 2015 8:17 AM


How many CyanogenMod users are running the latest though? I have CyanogenMod on three old Android devices, none of which will run CyanogenMod v12 and I don’t see them back-porting it to older versions either 🙁

Sasparilla July 28, 2015 8:43 AM

Saw this yesterday, puts the broken update model that Android and Windows Phone use into perspective.

Would you buy a PC where your PC Manufacturer and then your ISP controlled whether you got security updates or not? (and for the most part didn’t do them)

Android and WP’s update model is fundamentally broken for our market (where timely security updates are required) – and long term must be totally rethought or people will flee towards options that give them the piece of mind of timely security updates. Even Google’s Nexus phones (only the 6 has been updated for this) are only guaranteed for updates for 18 months…Apple is doing 4 years. Google needs to fix this. JMHO…

Nicholas Weaver July 28, 2015 8:47 AM

Stagefright really is an unmitigated and unmitigatable disaster: the worm potential is huge, the damage potential is huge, and the profit potential for attackers is huge.

A bet: Within the next 3 months, we will have a “wipe out 80%+ of Android for profit” event. Its just too attractive not to happen.

Andrew July 28, 2015 8:54 AM

@Kyle Rose
How will this convince anyone to start a proper software upgrade program?

Don’t know how it’s at your side of the world, but here if something potentially harmful takes place with your ISP account (say your computers get infected and start sending out spam), your account gets suspended until you first fix your tech and then go and ahem…. apologize to your provider. And I clearly remember similar clauses in my cell phone contract.

So I don’t really see a chance for “a worm like this that takes down the cell networks with an unstoppable flood of traffic”. If such a worm shows up and starts infecting phones, the said phones will probably be kicked off the network before you could get your wits together to say “Quidditch”.

Incidentally this will probably also mean increased sales for the phone manufacturing companies. Why would they want to fix the situation?

Winter July 28, 2015 8:55 AM

This is released roughly a month before the official publication of the vulnerability. I guess, they only put in enough information to make clear that it is real, but that they left out some crucial information needed to find the bug. At least I hope they did.

Now, Google and others will start to lean on ISPs and handset producers to do the OTA update, fast.

When there is a significant rate of infection in a few months, those ISPs and producers that failed to sent out the update will be held responsible for any damage. When it is not in legal terms, it will be in marketing.

Btw, now I understand the sudden OTA update of my Nexus a few months ago.

Kyle Rose July 28, 2015 10:03 AM

@Andrew: because in the US the phones are devices generally purchased from and provisioned by the wireless carriers.

If my computer gets pwn3d and starts sending out spam and my ISP cuts me off, chances are I’m one among few, and since it’s my third-party device the only recourse I might have is to Microsoft/Apple or the hardware manufacturer. If OTOH I bought a phone from AT&T and they unilaterally shut it off after a year, and the same thing happened to millions of other customers… that smells an awful lot like class action lawsuit.

eddie July 28, 2015 10:30 AM

The worm will never happen because the carriers will block transmission of anything that looks like it’s carrying an exploit or a payload.

Oliver July 28, 2015 10:37 AM

Are you seriously worrying about the manufacturers providing patches for this?
Ha, ha, ha, there are litterally no ppl that are even considering patching an ANDROID phone, NONE!
Apart from those CM users of course, but that is a tiny minority.


SJ July 28, 2015 10:39 AM

My Verizon hand-held has a “most recent system update” in late April.

I wonder if that means Verizon bundled the patch, or not?

Nicholas Weaver July 28, 2015 10:44 AM

Some more details:

The Android “Stagefright” vulnerability really is as bad as the press says it is: Malicious MMS message and, depending on the version, the exploit already has full system access and, even if not, has pretty high privileges and a world of local privilege exploits available.

And its worse already: although there is no public exploit code yet, the patches are known and identified, so building exploits are straightforward for experts. And even worse, the authors are promising PoC code after Blackhat, so even if attackers are too lazy to reverse engineer the patch, it will be out there.

And it can be even worse: It is downright trivial to turn an exploit into a full self-propagating worm:

Take over phone from a message.

Get root with one of the gazillion unpatched local privilege exploits (that is, if you aren’t already running as system)

Look through the contacts list, send to all in contacts list.

And there are multiple profitable payloads possible, providing motivation.

You can mitigate the possibility of a worm attack on some handsets.

The easiest vector to exploit is the messaging interface (although it can also be exploited by malicious web pages). So disable the ability to get multimedia content in the messenger is a huge win.

Under 5.1: Hangouts: Settings : SMS : Advanced Settings, unset autoretrieve MMS

I’m not sure about older versions.

This doesn’t keep a phone from being vulnerable by other vectors (notably drive-by pages and perhaps malicious emails), but it will keep your phone from getting wormed or being trivially targeted.

Carriers can also potentially filter MMS messages, but they need to start now: It appears possible to write an “exploit signature” which detects all attempts to exploit this Stagefright vulnerability by recognizing the illegal nature of the file. But such filters need to be put in place now before a widespread attack happens.

But overall, this is really REALLY bad news, and there really should be some contingency planning now on what to do if 1/2 the cellphones in the US stop working in the space of 10 minutes…

Daniel July 28, 2015 11:18 AM

I don’t use an Android phone but I simply fail to comprehend how anyone could have ever thought that pre-loading a file of unknown origin was an acceptable solution to any problem.

Rarely do I feel astonished anymore when it comes to security matters. This astonishes me.

Google has gone a long was to try and prove that it is serious about security and now this. How can anyone trust Google when it makes such an elementary error?

Nicholas Weaver July 28, 2015 11:23 AM

There is, however, some potential really good news, but we’ll see how it plays out.

1) It does look plausible to write a vulnerability signature (detecting the invalid files):

has the vulnerability details: detecting a non-NULL-terminated string in the metadata of the video file, or just string beyond a specified length, should be sufficient.

Thus it at least appears plausible to write a vulnerability signature: an IDS rule that detects the act of triggering the bug. Thus carriers could, theoretically, place filters in place now to block Stagefright MMS messages.

2) Google could push out a patch for Hangouts that pre-checks all media files for the vulnerability. Although there are numerous paths into the vulnerable library, the biggest one is through MMS messages. These days, Hangouts is the default messenger for most. Since Hangouts is part of the “Google Play” binary blob, not the phone OS, Google can put in a check into Hangouts and push it out to all phones which use Google Play, without relying on the OEMs to update.

3) It appears straightforward to backport this patch to older phones, so OEMs and carriers can fix older devices without having to port to the latest Android OS. Carriers should probably demand that OEMs do this.

There would still be vulnerabities and vulnerable paths even if all three happen, but either 1 or 2 could greatly reduce the possibility of a widespread attack.

Daniel July 28, 2015 11:25 AM

@eddie and others….

Right….because anti-virus works so well right now. And can one imagine the complaints if the wireless carriers error on the side of caution and induce many false positives. OMG. A wireless provider is damned if one does and damned if one doesn’t unless they manage to get the virus heuristics exactly correct, which would take divine intervention.

Nick P July 28, 2015 11:31 AM

@ Alastair McKinstry

“Care to explain why the answer is a new TCB from Google if the problem is that phone manufacturers won’t send out patches?”

With a strong TCB, the MMS app might have been isolated and comms from it guarded as such that it couldn’t do squat. There are existing products in defense and commercial space that do this with a combination of microkernels, user-mode Linux VM’s, and middleware to enable easy isolation & communication. The risky stuff can be isolated into partitions that reduce their impact. Further, with companies like Apple doing custom hardware, they could modify the processor and their vertically-integrated stacks to enforce stronger security invariants that knock out most classes of code injection. That CHERI team already ported FreeBSD to capability-secure processor and toolchain with fine-grained isolation showed that multi-billion companies could do same for smaller system.

In the end, no improvements will be made to the TCB and little things such as MMS will continue to cause problems. The commercial vendors such as Green Hills, SYSGO, and OK Labs will continue to supply isolation and security mechanisms for companies willing to pay for them. The mainstream stuff will still boost hackers’ productivity via design and implementation decisions with carriers’ patching policies being icing on the cake. Resourceful users will reduce risk by jailbreaking, applying mods, doing hardening, stripping functionality, backups, updates, and periodic restores just in case. Basically the model for protecting Windows boxes, especially before Lipner’s SDL. Least the Android phones are easier to mod and support isolation mechanisms for those inclined to build them.

@ Nicholas Weaver, all

The regular messages app also has a settings menu with the same feature. For anyone not using Hangouts.

“But overall, this is really REALLY bad news, and there really should be some contingency planning now on what to do if 1/2 the cellphones in the US stop working in the space of 10 minutes…”

I’m sure the U.S. will experience both a crisis and the largest productivity boost many companies have seen in years.

Bob T July 28, 2015 11:44 AM

@SJ • July 28, 2015 10:39 AM

It means you have reached your limit of one updates. No updates for you!

Who? July 28, 2015 11:51 AM

Lack of patches is the real issue here. Of course design matters, a huge kernel bloated with millions of lines of code is not a good starting point, but the key here is lack of support from manufacturers.

  • how can one year old tablets/phones be declared obsolete/unsupported by manufacturer?
  • how can one year old computers not have firmware updates?
  • how can manufacturers ignore high quality patches that developers give them for free?

Even expensive ThinkPads are declared obsolete after just three years. Any BSD/Linux/Unix operating system does more on this matter — these operating systems can be upgraded for free once they stop getting updates. A one year old computer/phone/tablet is a powerful device yet, but lack of support turn them into expensive paperweights from the point of view of security.

We can do a lot about patching at the operating system/applications level, but firmware should be supported by manufacturers for more than just a few years. It is just a matter of responsibility. And Android is, in some way, more firmware than an operating system. There is not a generic “Android image” than can be flashed on any device. We need support for more than one year, we need upgrades at least for critical issues.

This one is the greatest differences between hardware and software manufacturers. The former do not do a decent work supporting software, they never did, they do not care because their are in the business of selling hardware. This is the reason I choose good hardware manufacturers for hardware, but never trust the software they give with their products. But the firmware remains as one of the weaknesses of these devices, and this one is an area software manufacturers cannot control. This critical software remains on the hand of hardware manufacturers that hate software development, corporations that do not care about the software they provide with the computers they sell.

Nick P July 28, 2015 12:31 PM

@ Who?

The lack of patches is a big part of the issue. They sure could get them out faster and support devices for longer. I was going to say they shouldn’t given their environment and incentives but you figured it out:

“The former do not do a decent work supporting software, they never did, they do not care because their are in the business of selling hardware.”

Their responsibility is to shareholders. That profit over everything mentality, no liability laws, and consumers apathetic to security combine to get current situation. Vendors of hardened phones and mods that update right have a tiny market share compared to Android as a whole. This is true for almost every product in every category that does this. Vendors noticed this long ago. Responsibility has to happen on the demand side first or profit-driven companies have no incentive to perform on their end. Some can differentiate but most consumers buy phones for features, price, and appearance. Companies see as a waste of profit spending money on protections consumers rarely ask for and more rarely buy.

Consumers, legislators, or courts need to change their habits first. Then we might see something happen on vendors’ end. Otherwise, they’re continuing to vote for this exact situation with their wallets and political choices.

Note: Intel made the mistake three times of trying to change to a more secure and reliable processor architecture. Total losses of over a billion. Happened with OS’s, browsers, firewalls… you name it. Insecure shit from untrustworthy companies flourished. Suppliers took notice & changed behavior accordingly. Right thing to do in their position.

Clive Robinson July 28, 2015 12:40 PM

@ Nick P, Thoth, Wael,

This comment raised a wry smile,

SilentCircle, maker of the Blackphone Android handset, has also patched the vulnerability in it’s PrivatOS…

As we predicted it would be as vulnerable as any other Android phone.

The real question is as it can be turned into a root level attack just how vulnerable their “add on” secure code is…

I guess I’m going to leave off upgrading this phone for a new one just a little while yet, so as the contract provider will not be able to claim they are not aware of the problem…

And I guess it’s time to “root” the tablet I’ve just got and permanently “kill” a few things off… Oh the joys of being “mobile” these days, it makes me wonder why I ever gave up on XP 😉

Anura July 28, 2015 12:52 PM

The big problem with Android is practically every single phone seems to require a different build. This means that third party ROMs are going to be outdated for some phones, no matter what. Because of the reliance on hardware vendors and wireless carriers to distribute them, it turns a major flaw into a nightmare.

Tõnis July 28, 2015 1:05 PM

Aren’t android and google just wonderful, the best?!? Happily using BlackBerry 10 hardware and os all running safely on the QNX microkernal.

Nick P July 28, 2015 1:09 PM

@ Bruce, Clive

Remember in our discussion here on Cryptophone that Frank Rieger warned us about this sort of thing:

“MMS is removed by default in all security levels, as it is a horrifying protocol that allows an attacker to send 100K of binary through a set of really badly written parsers onto the phone. Also removed by default is SIM Toolkit, which is older but equally nasty. In the upper Security Manager levels, the IP stack is deactivated. We did this btw. long before it became public that MMS can be broken, as we conduct our own audits (if necessary on the binary) of critical components of the OS and rather remove a feature that we feel bad about then risk it being exploited.”

Well, security engineers knew the risk but I’m more giving due credit to them for eliminating it in preliminary, security review. They preached about it in public presentations. That MMS-enabled, Android phones would be owned was both predictable and inevitable.

@ Clive

It’s no surprise. Hardened Android can’t buy them much any more than hardened Windows, Mac, or Linux did. It reduces some attacks while leaving other, preventable ones due to architecture and implementation. Rieger at least acknowledged this and said they were investigating ways (eg microkernels) to lower TCB. Don’t know where that went. There’s quite a few commercial solutions for lowering TCB with Samsung using one for Knox family and another widely deployed for baseband isolation. So, there’s options but they seem to have avoided them probably for financial & labor reasons. The results will be similar to other merely hardened phones.

Honestly, they’d have to cut out at least as much as Cryptophone on WinMoble did before I’d start to trust it and we both know Android users won’t sacrifice that much functionality. It’s also getting too complex for that to be easy. I’d probably partner with a modding community such as Cyanogen as there’s overlaps between the two’s needs and would reduce work.

@ Anura

That’s certainly a contributor. I told them in the past they’d have to mostly automate their processes for getting from patches to all the different builds. They should be doing that already just to reduce labor. The next change is going from that to pushing updates more consistently. Aside from not spending, they might not want to do it for bandwidth reasons: each update I get is almost a GB and that’s quite a lot of updates multiplied by all their customers. Maybe they could stagger them to reduce the load. Or finally invest in a diff engine like we did to cope with 90’s era dialup. 😉

@ Tonis

“Happily using BlackBerry 10 hardware and os all running safely on the QNX microkernal. ”

An example of a company going in the direction I wrote about above. I gave them props for that when they released Playbook. Demos doing comparisons made me go “Holy shit!” Curious, as I don’t use a BB10, did the new OS improve speed of apps or latency of messages?

Tõnis July 28, 2015 1:47 PM

“An example of a company going in the direction I wrote about above. I gave them props for that when they released Playbook. Demos doing comparisons made me go ‘Holy shit!’ Curious, as I don’t use a BB10, did the new OS improve speed of apps or latency of messages?”

@NickP, I was a BlackBerry legacy os holdout for the longest time, because I feared email would be less reliable without the BlackBerry Internet Service (BIS). What I’ve found is that it’s at least as reliable as it ever was. EAS emails hit my device as fast or faster than they hit my computer. The POP accounts of course poll.

As for apps, that’s the biggest gripe most consumers will have about BlackBerry: the limited number of available popular apps. I’m not an app person, and for the most part my BlackBerry does most everything I need right out of the box: email, instant messaging, voice/video calls or wifi and the mobile network, PIM, maps/navigation, etc.

What I also love is Remote File Access of my pc over wifi and the mobile network using the BlackBerry Link program. The Browser is awesome with good html 5 performance; the newest versions no longer support Flash, but my carrier’s latest official version still does.

BlackBerry 10 has an android runtime users can use to load android ports and if ports are not available to sideload android applications. I actually have one: Skype. It’s a port available in BlackBerry AppWorld. Users complain that as an android port it’s not great compared to a native app or the many other android versions running on android devices, but I find it works fine for me. Voice/video calls work well, and messaging syncs well and is otherwise reliable.

I’m confident my data at rest is secure. Picture Password ( saves me from having to type my 32 character complex random password a hundred times per day.

Nick P July 28, 2015 3:04 PM

@ Tonis

Appreciate the review. Sounds like they’ve done a lot of good work on it. Hopefully management gets their crap together so we can get out of the duopoly we have.

8398943857384 July 28, 2015 5:39 PM

Prepaid and budget phones aren’t even updated past older vulnerabilities.. Nobody mentions this in any Android article..

fattire July 28, 2015 6:35 PM

So I’ve been thinking about the Morris worm and how it clogged the fledgling Internet due to overzealous replication…

So my question– how well are the mobile networks + POTS around the world going to handle a mass of attacks/mischief if millions of phones decide to spam every phone # in the phone’s contact list, then start wardialing random numbers? This could affect not just Android owners, but everyone– when the network jams, or even if iPhone users are inundated with endless messages and emails too.

Not to mention unpatchable android botnets intentionally focusing DDOS attacks on phone numbers or ranges of numbers…

@Nicholas Weaver:

Yes, I’m hoping that Google updating its apps to make it a bit harder to trigger attacks… I imagine it could make a difference in how quickly it would spread.


Anura July 28, 2015 7:01 PM


Depends on the area. Out in the boonies population density is low, but wireless coverage is going to be poor anyway, so whether that makes attacks easier or harder I have no clue. In a dense urban environment, a worm traveling through MMS with every phone sending to everyone in the contact list could crush the network.

samuel July 28, 2015 9:13 PM

The assertion that this bug is trivial to weaponize is false. ASLR is a significant mitigation on any Android release > 4.1 (that is, any release of android in the last ~3 years). This makes successful exploitation of vulnerabilities such as these plummet in terms of reliability to working once out of every X thousand times (precise value of X depends on entropy). Further, though the service respawns on crash, Android has a built-in backoff algorithm for respawning services that have crashed. To exploit a modern Android phone, you would have to send thousands of MMSs over a period of days or weeks.

We won’t see a worm from this bug because essentially, it won’t work.

Coolknight July 28, 2015 9:20 PM

As long there is no legislation forcing manufacturers and carriers to patch phones in 14 days max once an issue is public knowledge, there will be no fix. Carriers must be forced to distribute any security updates quickly and to abandon branding and locked devices. They must also be forced to deny data services to devices that don’t receive any updates anymore. Apple has also done nothing about a bunch of email vulnerabilities, it is not just an issue with Android or Windows Phone. The real problem is lacking legislation which allows manufacturers and carriers to get away with such disastrous policies.

Thoth July 28, 2015 9:58 PM

@Nick P, Clive Robinson, Bruce Schneier, Anura, all
I think we are better off with paper and pencil if it’s anything really sensitive. A normal computer or phone for browsing, and with restricted usage in the sense the user makes informed choices would still be fine.

I guess we have to settle on the fact that even “relative security” cannot be achieved due to the current market conditions and level of ignorance, World Warhawk Govts (hating secure technologies for others) and nay sayers. I do not mean there are no available “relative security / assurance” technology like KNOX and Secure Enclave but the fact that few even heard of it and even bother to dig around or buy one to give it a try due to the fact most of the security features must be spoon fed and baked inside in a very obvious manner and as a requirement for users during system setup meant that Security and Assurance as it is has failed to be propagated in a way. One example is giving a user a secure option and an insecure option for their personal use and they would inevitably lean to insecure options just for the additional ease of use.

Put it simply, if you don’t want to have a piece of data exflitrated (like sensitive photos and such), you should not even have it there in the first place and let known at all.

Ultimately, something that does not exist is the most secure as it never existed in the first place (yes, a piece of Zen moment).

It’s quite tiring to play the cat and mouse game of security and that’s what most people are feeling when vulnerabilities appear and the apathy simply continues.

If a proper TCB with a relative security setting were there in the first place, incidents would be lesser, exploitations would be harder and there would be less frequent play catch games and more productivity and reduced patching cycles 9although that does not mean one can shrug off patching altogether).

The cycle goes on just like the snake eating it’s own tail 🙂 .

Clive Robinson July 28, 2015 11:47 PM

@ Thoth,

The cycle goes on just like the snake eating it’s own tail 🙂

That expression comes back to haunt me…

I don’t know if you were around back then, but I used it as part of an explaination of how to hide / secure a crypto key in systems memory quite a few years ago. A simple version is two ring buffers and a generator that runs continuouly changing the values, hence my describing it as a “snake eating it’s own tail”.

I don’t know if I was the first to come up with the idea, or not, but I had never seen anybody publish or put on the Internet the idea.

A few years later I explained it again and RobertT mentioned he had found/seen a similar idea using a Lorenz Attractor,

If you’ve not read that thred it’s still very timely, you will even see the issue of Blackberry phones we were talking about a few days ago mentioned.

Clive Robinson July 29, 2015 12:13 AM

@ Nick P, Thoth, Wael, and others into TCB and similar security,

As part of my thinking on C-v-P I decided to split the kernel up to reduce the attack surface in the prison cells.

The idea I came up with is probably not new but, finding good original security ideas can be tough, and most of what’s published is just a small increment on something else.

What I decided to do was put only the top of the kernel API in the prison cell and this could be done with just a K or so of compiled code and a “letter box” buffer for communication.

I guess I got the idea from several places, including the more modern car radio’s which to reduce crime have a removable small user interface, with the real guts of the radio hidden away where it can not be easily got at.

Well it appears I’m not alone in the idea, Antti Kantee used it for his PhD dissertation. T(he)y are still working on the idea and improving it and writting a book about it. And has given the idea the terms “Rump Kernel” and “anykernel”. It’s worth a read, just about how it makes porting code to new hardware and developing new device drivers etc, without bringing the world down around your ears,

Thoth July 29, 2015 1:08 AM

@Clive Robinson
To put it simply, your Ouroboros method (snake eating it’s own tail) is using XOR to share pieces of data with one portion in RAM and another in CPU or somewhere else right ? If that’s correct, you did mention it recently I think but that might be beginning of this year or late last year when I recently became more active.

arkanoid July 29, 2015 8:55 AM

I wouldn’t be so sure Blackberry 10 is immune. It may either use the same library natively or have it in Android subsystem, but the result is still the same.

I personally think the majority of BB security hype is total bs. And even that those losers were unable to exploit properly: after Snowden they could make a “better Blackphone” and claim their market share back. But they did not, they did absolutely nothing to make security features available to customer.

rgaff July 29, 2015 9:14 AM


“after Snowden they could make a “better Blackphone” and claim their market share back. But they did not, they did absolutely nothing”

This I want to point out! Being called out by a whistleblower, and then doing ABSOLUTELY NOTHING about it, and simply ignoring it…. THAT is equivalent in my mind to screaming at the top of your lungs, “but we’re complicit in all this, we WANT the government to spy on all our users through our products”…. I mean, really? doing nothing about it? it’s been over 2 years now… what the heck… you do nothing you deserve every bit of your coming bankruptcy in my opinion!

I mean, at LEAST that Apple guy did SOMETHING… not much, he didn’t really fix much, but he did something when he added full disk encryption…. sheesh!

Gweihir July 29, 2015 10:57 AM

@Nicholas Weaver:

I agree that we will see some topological-scan fast worms from this. This will not get quite the same speed as the fastest old worm (around 15 minutes to saturation for Witty, if I remember correctly), but something like a few hours to saturation seems entirely doable. That would be on par with Blaster. No manual counter-reaction can deal with these speeds. I also do not see any signatures being in place, as deploying them is likely even more difficult than deploying patches.

Interesting times again. Maybe this time people will learn something. Somehow I doubt it though. Seems the same mistakes have to be made over and over again on any new type of computing platform. The next one after this may be a fast worm that spreads between cars…

Nick P July 29, 2015 11:35 AM

@ Clive Robinson

re RobertT

I’m still amazed he even figured out what he was looking at. Working from a Lorenz Attractor to an encryption scheme is one thing. Working backward from ALU and RAM behavior to rings and Lorenz is another. Talented dude. However, it dawned on me that hardware people often use things such as waveforms in their work. I found this page where it shows Lorentz has a straightforward waveform. Doesn’t mean that’s what he saw with his instruments but he might have seen it before in college or something.

re snake eating its own tail

The best implementation of the idea that I’ve seen is the movie Predestination: the messed up story of one time traveling agent’s (Ethan Hawke) pursuit of a terrorist and understanding his own life. Skip the trailer since it’s spoilers on overdrive. If you like time travel and paradoxes, just watch the movie if you like the synopsis and time travel paradoxes. The movie layers paradoxes on paradoxes with some evil schemes implied but not stated. Very well done. By the end of it, you’ll have a newer, better impression of “snake eating its own tail.” 🙂

re rump kernel

Yeah, it’s a variant on a pre-existing concept. Deprivileged, complex API’s layered on top of trusted, minimal, kernel API’s is the standard fare going back to Orange Book. On driver side, the OKL4 kernel let you (a) put drivers directly on the kernel, (b) reuse Linux drivers with a thin, user-mode wrapper, or (c) use virtual drivers that pointed to (a) or (b). It was a clever addition that allowed lots of flexibility in design and implementation. The rump kernels are the mainstream answer to it. Actually good that the concept is reinvented and mainstreaming because more labor is what it needs to work.

@ arkanoid

“And even that those losers were unable to exploit properly: after Snowden they could make a “better Blackphone” and claim their market share back. But they did not, they did absolutely nothing to make security features available to customer.”

I totally agree. I’ve blasted them repeatedly for being in the prime position to differentiate on that and in the enterprise market (aka I.P. protection) where people kind of care. Instead, the fools did everything they could to pretend to be iPhones or Androids while the latter added features and apps to replace Blackberries. It’s one of the most EPIC FAILS in the history of the phrase.

Thing is, there’s still a chance for them to make a comeback. Post-Snowden was the best thing that could’ve happened to them. The trick would be to selectively open-source key functionality, especially underlying kernel, to demonstrate no subversion. Their QNX microkernel and user-mode services give them an advantage over at least Microsoft and Google in that simplicity faciliates review. Worst case scenario, trusting nothing but kernel, customers could run security-critical apps on kernel directly with untrusted stuff in main BB10 partition. They would just check that their kernel was the verified one, build new software against it, build BB10 against it, and load that onto the device.

Blackberry is instead showing very little creativity. Not surprising given the territory they come from. 😉

winter July 29, 2015 9:11 PM

Google announced that they will send out an OTA patch to nexus devices next week. That seems to be rather late if they had the patches since April. Especially when you consider that the bug will be out only days later.

A positive interpretation would be that Google has organized an Android wide update by all partners at the same time. That would be a sensible thing to do as the bug would be out at the first real patch release.

I know, this is a charitable interpretation and I fully expect the partners to drop the ball.

The Open Source reslease will come only after the official presentation of the bug. I wonder what the AOSP vendors can and will do?

Winter July 30, 2015 12:32 AM

“i.e. it’s late on purpose due to collusion between Google and the IC using their 0-days.”

If a stagefright worm takes out most of the Android phones, Google’s profits are going to suffer. Not just a little, but their profits could be wiped out for years to come. Their fortress in mobile is at stake and therefore, their future.

Getting the patch out to over a billion handsets will be a challenge in any persons book. Delaying it unnecessarily would make that only much, much harder.

So, I would like to know what kind of incentive would motivate Google to gamble its very existence only to extend a years old 0-day for a month? What morons in IC would risk their hold on the mobile communications of the world for a one month extension?

rgaff July 30, 2015 2:36 AM

@ Winter

What morons in the IC and in the entire Presidency and Congress would think that undermining the Constitution and the very fabric of Democratic and Judicial processes themselves is “worth it”? I’d say they’re not known for having their heads on straight! So in my opinion, pointing out the stupidity isn’t a good argument that it can’t happen. Of course you’re welcome to have a different opinion.

As to how company executives can risk their whole companies… well, I’d say they probably initially thought that the government would protect them, but now the government probably terrorizes them with threats of long prison sentences… I just can’t think of any other reason for so many large companies to be so sluggish in getting patches out.

Wait, I can think of one other reason: complete, utter, irrational denial of reality. Some people think they are so powerful that they can command anything into existence, even things that defy basic physics and logic, as if they are some sort of deity. I’ve had former bosses like that, the key word here being “former” 😉

Hardeep Singh July 30, 2015 3:30 AM

Android app security seems like an endless Tom and Jerry Fight. Along with the alarming growth of the user base, android is the most vulnerable mobile OS of today. Android, being an open platform for publishing of app have made it highly accessible to developers, and also to hackers.

Stagefright is called the “mother of all Android vulnerabilities,” as this bug puts some 950 million Android phones at risk of hacking. No one has exploited the vulnerability and actually hacked someone’s phone — at least, not yet. The security firm that found the bug, Zimperium, shared the information with Google back in April, along with a suggested patch. This means that chances of you getting hacked are pretty slim. But if you are an Android user, the chances that your phone is vulnerable are about 95 percent.

The need of the hour for developers and enterprises is to be aware & proactive towards mobile security. Its a priority for us at Appknox (www.appknox). We help businesses and developers in securing their apps and alerting them to new vulnerabilities as they arise.

name.withheld.for.obvious.reasons July 30, 2015 4:58 AM

@ Hardeep Singh

Along with the alarming growth of the user base, android is the most vulnerable mobile OS of today. Android, being an open platform for publishing of app have made it highly accessible to developers, and also to hackers.

Neither sentence is “factual” and is at best a hypothesis. Fact, the second sentence is refuted by empirical evidence thus far. Sufficient research that correlates the availability of source code or platform schematics/drawings/Gerber files and the level of platform security does not exist.

This goes to one of my original statements, the problem space(s) is insufficiently enumerated or quantified to establish a level of “completeness” when it comes to defining “functional” security. Bruce has gone to some lengths in making risk analysis a part of the process of development, several of his books detail both the operational and developmental components of information security. His is an applied approach which could be instructive to the would be developer/programmer/etc..

There are efforts to formalize many aspects of computational theory but alas, their fate remains within the realm of the theoretical and not the applied.

D July 30, 2015 8:12 AM

I have installed android runtime on my blackberry. have i introduced the problem?

my MMS on blackberry is not the same as android, but many of the android apps seem to have crazy high permissions.

facebook and skype apps push their contacts into my blackberry contact list for instance. this drives me nuts, as these are not the best ways to get hold of people, and i never specifically said to perform the task. maybe somewhere i had to give permission to run skype and facebook, but that permission is an empty excuse to invade my personal space.

any word on google runtime on a blackberry? is there anything about a blackberry that makes google apps safer, because it is all apples and n oranges? oh, an accidental pun!

Tõnis July 30, 2015 5:11 PM

@D, My BlackBerry Q10 came with the android runtime already installed, so I’m not sure what you mean when you say you installed it or how one would even go about doing that. In any case, as I understand it, applications on BlackBerry 10 are all sanboxed, so I would think that the text messages applications is safe. Also, I never heard of any BlackBerry ever allowing an application to install itself without the user performing the task.

Yes, all android apps on the BlackBerry allow every permission by default, and there is no way to turn any of them off. My Skype app has every permission enabled, and the toggle switches are grayed out and can’t be switched to off I only have the one android port (Skype), but I’ve read that that’s the case with every android app. That’s also one of the reasons why I don’t have more android apps; I risk it with Skype. On the other hand, native BlackBerry 10 apps and apps made by others for BlackBerry have fully customizable permissions. For exampIe, I have native BlackBerry 10 apps like Google Talk and Yahoo Instant Messenger set to allow access to shared files, but I have permissions other ones like Evernote (made by Evernote Corporation for BlackBerry) set to disallow access to shared files, microphone, device identifying information, location, etc.

Anyway, here’s the link to a BlackBerry PDF document that explains BlackBerry 10 security:

Found this, too:

Caspian August 1, 2015 3:35 AM

Is there place collecting advice on what users or app developers can do about this? Most of the advice I’ve seen is only about avoiding the MMS vector. Here are the Stagefright bug mitigation ideas I have so far:

Official updates – probably won’t be coming soon for most phones from the big western manufacturers. May be available for some Nexus phones.

Install alternative OS. E.g. Cyanogenmod.

Application patches – warn before downloading files of the type that can trigger this bug, e.g. media files. Or disable them if not needed.

Application patches – check and filter malformed files that would trigger the buffer overflows. This could be done either server-side (basically using an app-specific proxy) or client-side. If client-side, you may need to avoid using the built-in Android download system in case stagefright gets hold of the unfiltered files.

Many web browsers already have optional proxies for reducing data usage.

Application patches – if you use stagefright internally, patch it. I gather Firefox has a patched version. Not sure if there’s still a risk of it downloading files to where the system can run its buggy stagefright on them.

Application avoidance – stop using any applications that download media files without sufficient countermeasures. That could include instant messengers, e-mail clients, web browsers, programs that display ads, as well as anything with MMS capabilities.

Filter running on PCs – a program running on a user’s own PC or other non-android device (or patched android device), that can check files for triggering buffer overflows or the stagefright bug, either rejecting or fixing them.

TomTrottier August 3, 2015 2:20 AM

Now! Portable botnets of milliions!
Telephone DOS attacks!

I believe it can prevented by disallowing any downloads of MMS videos by any application – like Hangouts & Messaging.

I wonder if other video processors are vulnerable. Web pages? Youtube?

@anura geographic area doesn’t mean much. What matters is how many contacts you have in your phone, and then how much local congestion there is.
A maximum effect infectious worm would MMS 1 contact per area code until all the contacts had been sent the fatal file. Within the last area code, once all the other area codes had been handled, exchange by exchange.

@gweihir That depends on the length of file necssary. If a few KB, fast, if a few MB, slower….

@Bill If it has to keep trying to get shell access, then the infection speed will depend on whether it’s 1 in 10 tries, or 1 in 1,000,000. If a high number of failures, it should be easy for carriers to ID & block video MMSs from the problem phones – they will be causing huge traffic overloads.

@Caspian – Since Firefox has an alternative video processor, and is open source, if should be fairly easy for developers to use it’s source. Too bad Firefox did not create a Stagefright alternative library!

Clive Robinson August 3, 2015 4:45 AM

@ TomTrottier,

Too bad Firefox did not create a Stagefright alternative ibrary!

The major failing of nearly all software security is building on the shoulders of those with feet of clay.

GCHQ, NSA, and others have known for years that this is the case, hence you backdoor the specifications of the standards and you have between a quater and half a century of usage of the backdoor.

Now people have finally “Officialy woken up” to this we have to watch out that they don’t slip us a “Mickey” and we end up sleepwalking into another crisis in ten to twenty years…

David L August 5, 2015 2:53 PM

Hi all,

Trend micro has discovered two NEW stagefright hacks. See this blog post:

And the comment here by those from 360 mobile security had some additional information,such as, when screen is in locked mode,this setting should be in place. System settings- sound and notification- hide sensative notification content. Also,some file managers with media players are vulnerable. 360s comment and link to post is just above maybe 10-15 comments previous.

And finally,I’m sure a great many people are awaiting the talk by Zimpierium security at Blackhat USA 2015. But brace yourselves,there are many more Android vulns yet to be revealed this year. A bumper crop I would say. And just before all these, Google’s Adrian Ludwig,head of android security,will give his talk,about how safe Android really is. Hope he has a tuff skin on this year,because he will look mighty foolish,to sat true least!

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.