Skip to content
Android. Image courtesy of Bloomua / Shutterstock.
Naked Security Naked Security

The “Stagefright” hole in Android – what you need to know

Here's what you can do to deal with the much-talked-up "Stagefright" messaging vulnerability on Android

Android. Image courtesy of Bloomua / Shutterstock.

Android phone image by Bloomua, courtesy of Shutterstock

The conference circuit can be a competitive arena, especially when there are multiple parallel streams.

For example, back in 2010, I was at Black Hat in Las Vegas, and I attended the talk next door to the late Barnaby Jack’s now legendary “ATM Jackpotting” talk.

Jack famously made unmodified ATMs that he bought off eBay cough up banknotes live on stage.

Those of us next door had to wait until the ovation and commotion died down before our presenter could continue lecturing to his meagre audience. (At least there was a good choice of seats.)

Exploit Disclosure Silly Season

So it’s not surprising that July tends to be Exploit Disclosure Silly Season.

Presenters at Black Hat and Def Con try to convince the media to tell the world that theirs is the talk to choose, stressing the severity of the hole they’ve found without giving too much away.

There’s nothing wrong with that: good talks based on solid reverse engineering aren’t easy to put together, and if you’re prepared to do a live demo to go with it, you’re entitled to your “jackpot” moment.

So, imagine that you’ve got exploit talks accepted at Black Hat and Def Con, that your hack is a remote code execution hole in the world’s most widespread mobile operating system, and, best of all…

…that the operating system component in which you found the bug is called “Stagefright”.

That’s a better name for an exploit than POODLE or LOGJAM – heck, it’s a better name than Heartbleed‘ (although the bugs don’t really compare at all, whatever you may have read).

You can use a name like “Stagefright” in your press releases without being accused of hyperbole.

Unsurprisingly, then, that’s what researchers at Zimperium have done.

They found a bunch of security holes, now designated with seven different CVE numbers (CVE-2015-1538, -1539, -3824, -3826, -3827, -3828 and -3829).

It’s become the “Stagefright” hole.

Multimedia Messaging System

The bugs are in an unfortunate part of Android: a part that is used by the Multimedia Messaging System, or MMS.

Remember MMS?

Like SMS but with videos, sounds, pictures, and no annoying 160-character limit?

It’s an aging system that doesn’t get a lot of attention these days, because internet-based programs like WhatsApp, Snapchat and Instagram have swept it aside.

But most Android phones are still set up to receive MMS messages, and will process them automatically by default.

Technically speaking, an MMS arrives as a link, so that the actual content of the message (which might cost you money) is fetched only later on, when you decide that you want to look at it

That’s a bit like email clients that fetch only subject lines at first, so you can ignore or delete unimportant messages without racking up download charges.

But the default SMS/MMS apps in Android 4.4 (KitKat) and 5.x (Lollipop) are Messaging and Hangouts respectively, and their default configuration is to download MMS content in the background as soon as the messages arrive.

Remote Code Execution

Unfortunately, the bugs found by Zimperium allow shellcode – executable instructions disguised as harmless multimedia data – to take control of your device as soon as the content of a booby-trapped message is downloaded.

So, you may be able to trigger malicious activity as soon as a victim’s device receives your poisoned message, even if they later decide to delete it.

That’s what’s known as a Remote Code Execution (RCE) vulnerability, almost always the worst sort.

The bug has been around for some time, and Zimperium is claiming that 950,000,000 devices may be at risk.

(That precise sounding number seems to be simply a 95% vulnerability rate multiplied by a round one billion Androids.)

Patches coming

Google knows about the bugs, and has prepared patches.

Indeed, if you have a Google Nexus, and you have updated recently, it sounds as though you are already safe.

Sadly, we can’t be sure which other device vendors have already patched, unless they choose to say so, because Zimperium is keeping the exploits under wraps until Black Hat, when the whole world will find out about them (and presumably, how to exploit them) at the same time.

It also sounds as though rebuilding Android from the open source project (AOSP) won’t help yet.

Google told The Guardian:

This vulnerability was identified in a laboratory setting on older Android devices, and as far as we know, no one has been affected. As soon as we were made aware of the vulnerability we took immediate action and sent a fix to our partners to protect users.

As part of a regularly scheduled security update, we plan to push further safeguards to Nexus devices starting next week. And, we'll be releasing it in open source when the details are made public by the researcher at BlackHat.

In short, this sounds like a serious bug, and you should be looking for a patch as soon as you can get one.

What to do?

  • Try asking your device vendor whether a patch is available already. You may be able to get ahead of the game.
  • If you can’t get a patch right now, find out when to expect it so that you can apply it as soon as you can.
  • If your messaging app supports it (Messaging and Hangouts both do), turn off Automatically retrieve MMS messages.
  • If your device supports it, consider blocking messages from unknown senders if you haven’t already.
  • If your SMS/MMS app doesn’t allow you to turn off Automatically retrieve messages, consider simply switching back to Android Messaging, which does.

Unless your digital lifestyle hinges on MMS, we think that you will be able to live without it, and that blocking the auto-download of potentially booby-trapped MMS content is a great start.

Of course, even if you’ve turned MMS auto-downloading off, you still need to avoid clicking on suspicious MMSes – doing so would initiate the potentially dangerous download anyway.

So, if you see an MMS from a sender who’s never communicated with you before, consider deleting it.

And don’t forget that “Stagefright” isn’t specific to MMS messaging, but rather to the way Android renders the sort of content typically delivered by MMS.

Firefox for Android, for example, has recently been updated; it too was apparently vulnerable via web pages containing booby-trapped videos.

So, keep your eyes peeled for those patches!


How about a custom APN in which the MMS fields are left blank?


Won’t that kill off SMSes too? Might not be what you want. Also, this bug is almost certainly not actually MMS-speciic, but relates to rendering content that is typically delivered via MMS.

Apparently, Firefox (which I assume has its own copy of the stagefright library) has put out a patch for this bug, triggerable via a video you might browse to.


“Unless your digital lifestyle hinges on MMS, we think that you will be able to live without it, and that blocking the auto-download of potentially booby-trapped MMS content is a great start.

If you see an MMS from a sender who’s never communicated with you before, simply delete it.”

Not worded very well. That last sentence doesn’t seem to go with the previous paragraph. Deleting messages from unknown senders will do no good against a bug that is triggered as soon as the message arrives. I know you mean that the user should first turn off auto-downloading, which will prevent the bug from triggering automatically, and then not open suspicious messages, but one could read that last sentence and assume that your advice is just not opening suspicious message.


You read my thoughts correctly but I accept that it may sound as though I’m saying that deleting messages is some kind of alternative to turning off auto-downloading. Of course, deleting an already-aut-downloaded message could be too late.

I’ll see if I can word it better.


Even someone who regularly communicates with you could be sending you an infected MMS, (IF the infected MMS has been created to replicate itself) Best to disable auto retrieve and not use MMS until you get patched/get a new phone. I won’t miss it – I have sent 2 MMS’s in my lifetime – 1 to test the disable auto-retrieve.


I would assume that older phones (such as the Samsung Galaxy Nexus) are out-of-luck since Google no longer supports or patches those devices.


I received an mms about 10 days ago on the default messenger app on android, I’ve since deleted it, but is there a chance that my phone is currently hacked?


Can your images be used in internal communications to show employees how to turn off Automatically retrieve messages?


Hi, could you please send an email to to let us know which images you’d like to use and we’ll see what we can do! Thanks.


Could you tell me if “any” of the “Sophos” Applications on my phone will discover this threat?


The answer is, I’m afraid, “It depends.” (We don’t quite know what the threat is yet, or whether or not we’ll detect and block on any of the side-effects of a successful exploit. Zimperium are keeping it under wraps for now.)

I can say, unfortunately, that if MMS is used as the delivery mechanism (but see above for why this isn’t specifically an MMS bug), our SMS/MMS filtering component won’t stop the message itself, even though that would be a handy place to intervene.

That’s because Android 4.4 and later don’t support any sort of “filter chain” that runs before an MMS is processed. You have to set one and only one app to handle your SMSes/MMSes, and it is under no obligation to co-operate with other security software before it accepts a message. Earlier versions of Android allowed security software to intercept and filter messages before they reached your actual messaging app. I am not sure why Google changed this – it’s a bit of a pity, really.


Just FYI as it relates to “Google” providing “patch info” to phone providers and partners. I spoke with Verizon this AM and asked if they had developed a patch and/or had they been provided anything from Google.
I was told to disable “Hangouts” and to go to my “security Settings” in VZ Protect. and asked if I used “google messaging” if so turn it off. Then make sure that the “scan when a message is received” is on and schedule either daily or weekly automatic scans and lastly turn on “scan when message is sent or received” I asked if they will advise when the patch is available they said yes…but it just seed as though they are still behind the curve on this. The person I spoke with had to put me on hold several times to find out what to do???? so I don’t think that it is a real priority at this point for Verizon…or at least that is the impression I got.


At least they had some thoughts on the issue, and they have some mitigations to suggest.

This isn’t only about MMSes, of course. I think some of the coverage out there has given the impression that the bug is all to do with MMS – this might be because Zimperium’s blog article focuses on exploiting it via MMS.

If you are particularly worried about the MMS vector – a reasonable concern, I admit, as you can see from the article – then turning off auto-download of messages is a great start. If you rarely or never receive MMSes (I think I have had two in my life, ironically on my old-school non-smart phone, which simply told me it couldn’t do anything with them :-) then you are unlikely to face the dilemma of deciding which MMSes to open or not and can happily delete all of them :-)


The first advice to ask the vendor is hard if You have an Samsung. The reply i got from support was “it is probably in latest update” and on further questions he replied “there is no clear documentation on what went into the updates”


How come these type of issues are not tackled directly by Android with an all encompassing patch for the Lolipop/5.0 systems? (maybe I’m just a real Android newbie)

I have a Moto G (which is supposed to be on Google’s fast track list) on a “low cost” prepaid carrier in Europe, and I have not been “sent” a patch for this…

Even though this is a serious problem, as Paul Ducklin mentioned in a comment above, I have not yet ever received an MMS.

But still, a more uniform approach would be welcome.


I guess part of the problem is that the bug isn’t in an individual app, e.g. Hangouts, that you could replace/swap/remove or update off Google Play. The bug, as far as we know so far, is in libstagefright, and that’s part of the base OS, or firmware, build.

Same problem when Google had a series of holes in app verification due to buggy APK (ZIP format) file handling: the bugs were effectively in the OS distro. So although Google could say, “See! We patched them in double-quick time,” there’s a big difference between a patch that’s in the source code tree and one that’s compiled into the executable code that’s actually running on your device :-)

The ability to update OS components independently – which people are used to thanks to Windows Update, OS X’s “Updates” tab in the App Store app, and almost every Linux distro – is perhaps what’s needed, so you don’t have to wait for your vendor to “update the whole device,” so to speak.


Most custom ROMs patched this a while ago. In case anyone is leaning towards doing that.

Sophos Android Security can’t protect against this?


The Chomp and Textra SMS apps have put out new versions that claim to stop the exploit.


Presaumbly, they can stop suspicious MMSes that might trigger the exploit, though that doesn’t actually close the hole in the multimedia rendering library…


I think that i may be infected with this thing on my phone. I am getting tons of download files in my messaging apps that “disappear” when i download them. I REALLY HOPE I CAN FIND A FIX! And btw none of my antivirus softwares detect anything wrong with my phone…


I’ve started getting MMS texts from “unknown” senders these past two days. Handcent is telling my me APN settings are wrong and can’t download the message. I’ve never messed with any APN settings on this phone (galaxy s4). It wouldn’t load so I deleted the text. I’ve since gotten about three of these. Two unknown and one with a Colorado area code. I don’t know anyone in Colorado and none of my friends claim to have tried to send me anything these past few days. I just now set handcent to no longer auto download MMS content. Wonder if someone already attempted this against me?


I think my phone has been infected by stagefright. What do I do? Is there any way of catching whoever did it. I have galax y s6 active

I have systemlib.stage fright in open source license. A lot of them.


So preventing it from happening in the first place seems to be prevalent in this blog, however, will stopping the auto download of MMSes prevent the “hacker” from further receiving information about your phone and all of its contents? I have very nosey friends who like to pry into everyone’s business, so I’m pretty sure this exploit has infected my device. How can I know for sure and stop future information leaks via this exploit?


The exploit itself can be used to deliver malware, but if it does, you ought to be able to find that malware with an Android anti-virus. (Ours is free; see the “free tools” links below.)

As for closing the hole opened up by the exploit – for that you need to update your Android, which is down to your phone vendor or service provider.

As for stopping MMS auto-download – that would not stop a crook who had already infected your device from stealing data, because he could use email or an outbound web connection to exfiltrate information. MMSes could be used for data theft, but most malware doesn’t bother because it’s easier and less obvious to use the network instead.


Does the size of the download indicate if it could be infected? For instance, 32kb? friends have a tendency to forward messages, so knowing the sender really doesn’t matter if they are unaware of what they are sending around.


Not really. After all this time, I don’t know of any active exploitation of this hole, so I don’t know how big (or small) a booby-trapped message “attachment” would end up being. But I don’t think that size would be a useful indicator, especially if the crook started with a legitimate file (e.g. an image) and modified it to produce the dangerous version. Just imagine what range of sizes that would give him to choose from :-)


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!