Summary: MMS messages can cause Android phones to decode video with libstagefright, which is a C++ library with vulnerabilities and insufficient sandboxing, leading to remote code execution without user interaction.
You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. THIS IS URGENT. While the precise details of the flaw have not been publicly disclosed, this disclosure is sufficient for a skilled person to rediscover the flaw, which means that there is a considerable risk that someone will systematically use it on all the phone numbers.
Are those the steps for Android 5/Lollipop? I don't see any of those menus in settings.
edit: Ah it's in the actual hangouts app that you have to go to settings. Also if those settings are greyed out then you might not have Hangouts handling your SMS messages, so run the Messaging app instead and go to its settings to disable auto open of MMS.
Seems to me Google could just update the "Hangouts" app to handle this, assuming people download the update. Yes or no? I think news articles are saying you have to wait for your service provider to issue an update? Sounds like bad advice.
It's likely too late for panic, everyone is probably owned already. It has the best infection vector ever, unauthenticated, unsolicited messaging with an easily discoverable addressing method. What more could a worm want?
>It's likely too late for panic, everyone is probably owned already
That seems unlikely given that the researcher hasn't publicly released the details of the hack, and he says that "he does not believe that hackers out in the wild are exploiting it".
Is there a way to see if one is "owned"? Could we run a command or view a menu that would list an extra binary? Could we try to exploit ourselves in some way, like visiting a special website?
I occasionally get picture or video messages from iPhones on my Android phone which just crash the default Messaging app. When this happens, it's not possible to even delete them as the app crashes immediately upon displaying that message. The only recovery I've found is to delete ALL messages. Interestingly this has never occurred when using Hangouts as the messaging app, but the fact that a presumably legit (these were received from known senders) MMS message could crash the app indicates that there are flaws in the programming.
There would be a lot of side-effects being noticed if it were being exploited as widely as you suggest. For example, carriers would notice lots of unusual activity; MMS step-change at a minimum.
Presumably anyone exploiting this would end up sending such messages to many iphones as well, where they could not delete themselves. If there are no suspicious messages arriving on iphones, that suggests it may not be being widely exploited.
- They don't read hacker news so they aren't aware of this.
- They won't be able to disable auto downloading of MMS even if they did hear about it (think grandparents)
- They won't ever get an update to their Android phone to fix it (or be able to update it if one arrived)
Instead, why don't Android phone updates work like Chrome's updates do? I installed Chrome v1 years ago on my parents computer and today they are running version 44 (without any intervention on my behalf). They are fully up to date and protected without them having to even know about or run any sort of update.
Agreed. Even for those of us on Hacker News who know how to deal with this, what's our incentive for staying on Android? I really love the user experience of Android, but all this makes me think about is the next exploit and whether iPhone or even Windows Phone are more secure. At the very least they get patches in a timely fashion.
decode video with libstagefright, which is a C++ library with vulnerabilities and insufficient sandboxing
Why? Why, if it is known to be a poorly written library, is it still part of an official release? And why the hell are client messages allow to specify the level of media down to the library linkage? Wtf.
Alternatively use a different SMS/MMS client such as TextSecure.
To quote moxie:
"We don't do any pre-processing that involves stagefright. There are no technical details at all available about this vulnerability (for maximum hype), but you'd have to physically tap on the media and then click through a warning about playing media insecurely before stagefright got involved."
Hopefully google paid and/or blackmailed carriers into filtering these mms messages. I think that's really the only possible remediation when at least 50% of android phones are functionally un-updatable.
How would you filter out the offending MMS messages? People send legitimate videos as well; is the bug such that it's obvious which videos contain exploits?
I tried chmod 0000 libstagefright* but my rooted 4.4.4 wouldn't boot afterwards. Any ideas on how to disable the libraries without completely breaking android?
TextSecure does not decode MMS attachments until you explicitly open them. [0] Switching to it as your default SMS handler should protect you from drive-by infection through malicious MMS payloads.
Hopefully those who make texting apps will be sensible and push out an update that 1) has a message about the vulnerability and 2) that disables auto-downloading of mms.
Edit:And I say this because even though old phone don't get updated, their apps do. Tenuous at best, but still better than nothing.
Can you confirm whether this is specific to videos or whether it includes images? I just received a rather generic and very unexpected MMS from a friend and wonder if there's a worm on the loose already.
Wondering the same. I got a weird Google Chat message through Hangouts a few months ago. Tried to uninstall Hangouts but it's a "system app" and can't uninstall it.
Google might have to rethink Android's updating strategy, if vulnerabilities like this keep coming out. Of course it would be nice to never have to update some devices, but it's not viable if they are: a) As complex as an Android phone and b) Connected to the internet/phone network.
I completely agree. They can force their OEM's to follow rules regarding the installation of Google Play services and apps yet they cannot seem to force them to update their software. Every OEM that wants Google Play services and apps should be required to supply OS and critical security updates to their phones for at least 3 years.
What if the Android update system is split into two channels: critical updates and feature updates.
The latter can be issued via the OEM or carrier - whereas the former is issued by Google. Since Google own the trademark on the Android name (http://developer.android.com/legal.html), perhaps Google can enforce a rule that an OEM which ships it's device without compliance with the above cannot call their device an "Android device".
The issue as I understand it is that's impossible, because there's no motivated stakeholder who can perform regression testing to validate the critical update channel. And the device builds have deviated far enough from vanilla Android+kernel that they require their own.
Tbh, Google needs to work with the Linux groups pushing for more coherent ARM/device flexibility frameworks, then ban carrier and device manufacturer build modification below a certain level of abstraction. Otherwise they revoke Android branding + access to GApps.
Then they would at least have a base for eventually saying,
"We're going to enable a critical update channel where users take updates directly from Google. We will release these updates to you with a lead time in proportion to the severity. Unless the user has explicitly opted out, they will automatically receive the update after that period. If it breaks your phone, then users are going to stop trusting you as a manufacturer / carrier."
I've been saying this for years. Google needs to provide security updates to all versions of Android which don't change APIs or functionality. Just drop-in replacements to fix exploits. These need to be offered for a period measured in years to every version of Android they release.
Microsoft still releases regular security fixes for Windows Vista!
I really hope they do because I've been using Android since the G1 and am about to ditch it due to lack of updates being given to me on all the devices I have bought. Yes, I know that the manufacturers should push them out but I've got numerous devices including barely year-old Samsung devices (Galaxy Note 10.1 2014 edition) and they don't have recent Android versions. I also have an Android phone from Sony and my wife has a Samsung Android phone - no updates there!
(This is separate to the issue that there is ever-changing UI guidelines on Android making each app feel entirely different to another one which is like being in a nightmare and not being able to wake up or understand how it SHOULD behave).
As someone else said, you wouldn't be happy with a laptop that did not let you install Windows updates.
This is the same problem we have with Android, and I'm getting really tired of it and ready to jump ship. It's all very well saying Nexus devices will be updated but why distribute Android to all other manufacturers if they won't get or push out updates? I can't see anyone clapping for Microsoft if they just pushed out service packs and updates for the Surface exclusively.
The update strategy has been rethought and, frankly, I'd be surprised if anyone needs to release an OS update to fix this. Google clearly can and will just update the Hangouts app (if they haven't already). I'd expect most other manufacturers to just put an update for their OEM messaging app on the Play Store (if they don't already have a hook in something like an updateable OEM framework app they can use).
> But Adrian Ludwig, the lead engineer for Android Security, told NPR the flaw ranks as "high" in their hierarchy of severity; and they've notified partners and already sent a fix to the smartphone makers who use Android.
It sounds like the fix can't be (or isn't being) made in the hangouts app.
> Drake speculates that Stagefright has its excessive permissions and Internet access to satisfy some types of digital rights management processing or streaming playback.
It's a little confused. Stagefright is just a library containing the exploit. The component being (presumably) exploited is the mediaserver process. This is where almost all video decode/encode handling happens in Android (and other related stuff, like audio and camera).
And yes, the mediaserver has internet access so that it can fetch and decode streams on its own without forcing all I/O to go through a user process. Basically it's a performance optimization, though indeed probably one necessitated by having to wall off all that DRM handling in the first place.
That said, mediaserver, while it has lots of access to things that Android apps don't (e.g. open file descriptors to kernel vendor-specific drivers with lets-just-say-questionable security practices), is not a root process. And it's reasonably sandboxed in recent Android versions using selinux. An exploit into it may not be quite as device-cracking as is being claimed.
This is pretty awful code. I saw "buffer[size] = 0" and assumed immediately that was a past-the-end write, but they actually allocate size + 1 bytes. Urgh.
Next they introduced a check for strings shorter than 6 bytes because that's the shortest possible valid string. Why not just check for a valid encoding in the first place? There are too many implicit assumptions about the data going on here and not enough actual validation.
This entire module needs scrapping and rewriting with a proper FSM/parser generator.
And why is an MPEG4 metadata decoder directly handling UTF anyway?
Wow. Integer overflows and underflows all over the place. It's almost like no-one's ever even taken a fuzzer to this before, which would surprise me given that Google is usually relatively security-concious.
This code is probably written by embedded software engineers like myself. No one knows anything about security, and certainly hasn't heard of a fuzzer. If the code works, it ships.
The other parts of Android written in C++ are also a horror show, though I think they have gotten better recently.
And don't even talk about the proprietary HAL blobs or kernel modules. Unspeakable things happen there. And of course, libstagefright talks directly to these.
Can I configure my phone to reject text messages with attached video? I'm thinking that would protect me from this exploit, plus, as a bonus, I wouldn't get text messages with attached video.
EDIT: I appreciate the replies. I was really wondering if I can disable video attachments without disabling other MMS features such as pictures and long messages (in Android 4.3).
I'm pretty sure you can just turn off MMS retrieval, yeah -- either in your messaging app or the phone's network settings.
The only problem is that many phones automatically turn long SMS messages into a single MMS message. As I understand it, you might not receive those -- although I'm not sure about this.
Buried in the language of most consumer software and services is a mandatory binding arbitration clause. A while back, a couple of rulings came down from the Supreme Court that declared mandatory binding arbitrations clauses to be perfectly kosher, and state laws declaring such clauses invalid to be -themselves- invalid.
So. Good luck with a class action suit. You've likely agreed to a contract in which you waived your right to file one. :(
Yes, this sucks. I wish Congress would fix up federal arbitration law.
A bit over a year ago, I bought the first generation Moto X from... well, Verizon "sold" me the phone, but it shipped directly from Motorola, then owned by Google. For reasons I'll mostly skip (signal/reception), I needed to stay with Verizon.
I bought the Moto X largely on the... assurance ("promise"?) that this particular phone, coming from a Google-owned Motorola, would actually be updated expeditiously by not just the manufacturer but also, downstream, Verizon.
Well, about a month ago my still 4.4.4 phone received an update. FINALLY. Then I looked at the version information; still at 4.4.4 .
I tell you, Google, I'm about done with your mobile products. Not that I hate dealing with them, with Android, but the U.S. (and elsewhere?) ecosphere for them simply sucks.
At least I am at 4.4.4 . Were I at 4.4.3, the last I read I would be subject to a web component vulnerability that Google has refused to fix below 4.4.4 . I suspect there are a lot of phones and tablets stuck at 4.4.3 or below. In fact, my parents have one, a Samsung tablet sold to the by... VERIZON, about a year and a half ago. (And they didn't buy at the cheap/old end of Verizon's tablet offerings.)
I am DONE with this bullshit. Meanwhile, Apple seems to have added some efficiencies to iOS that now allow a 4s phone (not sure about 4) to work reasonably well.
I was staying away from Apple's rather closed ecosphere and attitude. I am seriously reconsidering, at this point. I need my primary phone to fucking work and be reliable. I'll keep the more experimental stuff to other platforms.
> Do you have to have the "Hangouts" app installed for this security vulnerability?
No. The flaw is present in the extraction of the image data from the MMS message. Anything that uses the system standard way of doing this, including but not limited to Hangouts, will be vulnerable.
Hangouts retrieves MMS messages by default. This can be disabled under Settings => SMS. Turning this off disables the automatic processing and thus the passive exploit, but opening an MMS message containing the exploit can still be done by hand.
You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. THIS IS URGENT. While the precise details of the flaw have not been publicly disclosed, this disclosure is sufficient for a skilled person to rediscover the flaw, which means that there is a considerable risk that someone will systematically use it on all the phone numbers.
edit: Ah it's in the actual hangouts app that you have to go to settings. Also if those settings are greyed out then you might not have Hangouts handling your SMS messages, so run the Messaging app instead and go to its settings to disable auto open of MMS.
Contrary to the NPR article, somebody further down this page said this hack may affect Messenger users too. So I'm sticking with Hangouts!
That seems unlikely given that the researcher hasn't publicly released the details of the hack, and he says that "he does not believe that hackers out in the wild are exploiting it".
they may also blast texts out to android only phone numbers (maybe if you gave your phone number to an android app)
Nuking MMS from orbit won't patch your phone.
- They don't read hacker news so they aren't aware of this.
- They won't be able to disable auto downloading of MMS even if they did hear about it (think grandparents)
- They won't ever get an update to their Android phone to fix it (or be able to update it if one arrived)
Instead, why don't Android phone updates work like Chrome's updates do? I installed Chrome v1 years ago on my parents computer and today they are running version 44 (without any intervention on my behalf). They are fully up to date and protected without them having to even know about or run any sort of update.
Why? Why, if it is known to be a poorly written library, is it still part of an official release? And why the hell are client messages allow to specify the level of media down to the library linkage? Wtf.
The author is trying to build up hype for their vulnerability. Maybe if they shit on stagefright enough they can even start selling t-shirts.
To quote moxie: "We don't do any pre-processing that involves stagefright. There are no technical details at all available about this vulnerability (for maximum hype), but you'd have to physically tap on the media and then click through a warning about playing media insecurely before stagefright got involved."
https://github.com/WhisperSystems/TextSecure/issues/3817
See also: https://news.ycombinator.com/item?id=9959070
[0] https://github.com/WhisperSystems/TextSecure/issues/3817
Edit:And I say this because even though old phone don't get updated, their apps do. Tenuous at best, but still better than nothing.
Yes, I know that Hangouts has GV integration, but it's pretty subpar. There isn't, for example, a decent Hangouts Chrome extension.
Deleted Comment
It's also pretty absurd that Google doesn't support security fixes in a 3 year old operating system (Jellybean).
If the NSA and other three letter agencies aren't using the exploit now, I bet they will have an implementation live within a week.
The latter can be issued via the OEM or carrier - whereas the former is issued by Google. Since Google own the trademark on the Android name (http://developer.android.com/legal.html), perhaps Google can enforce a rule that an OEM which ships it's device without compliance with the above cannot call their device an "Android device".
Tbh, Google needs to work with the Linux groups pushing for more coherent ARM/device flexibility frameworks, then ban carrier and device manufacturer build modification below a certain level of abstraction. Otherwise they revoke Android branding + access to GApps.
Then they would at least have a base for eventually saying,
"We're going to enable a critical update channel where users take updates directly from Google. We will release these updates to you with a lead time in proportion to the severity. Unless the user has explicitly opted out, they will automatically receive the update after that period. If it breaks your phone, then users are going to stop trusting you as a manufacturer / carrier."
Microsoft still releases regular security fixes for Windows Vista!
(This is separate to the issue that there is ever-changing UI guidelines on Android making each app feel entirely different to another one which is like being in a nightmare and not being able to wake up or understand how it SHOULD behave).
As someone else said, you wouldn't be happy with a laptop that did not let you install Windows updates.
This is the same problem we have with Android, and I'm getting really tired of it and ready to jump ship. It's all very well saying Nexus devices will be updated but why distribute Android to all other manufacturers if they won't get or push out updates? I can't see anyone clapping for Microsoft if they just pushed out service packs and updates for the Surface exclusively.
It is/was an issue in Stagefright.
Details of CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828, CVE-2015-3829 probably available soon?
It sounds like the fix can't be (or isn't being) made in the hangouts app.
Goddamn you Hollywood.
And yes, the mediaserver has internet access so that it can fetch and decode streams on its own without forcing all I/O to go through a user process. Basically it's a performance optimization, though indeed probably one necessitated by having to wall off all that DRM handling in the first place.
That said, mediaserver, while it has lots of access to things that Android apps don't (e.g. open file descriptors to kernel vendor-specific drivers with lets-just-say-questionable security practices), is not a root process. And it's reasonably sandboxed in recent Android versions using selinux. An exploit into it may not be quite as device-cracking as is being claimed.
Still, not a good thing at all.
Is it safe to assume that this attack vector is not a concern with Android 5.1? (or later)
They share the blame, too. They can't all just throw their hands up in the air and say "they made us do it".
Deleted Comment
http://review.cyanogenmod.org/#/c/103276/
http://review.cyanogenmod.org/#/c/103275/
http://review.cyanogenmod.org/#/c/103274/
http://review.cyanogenmod.org/#/c/103273/
http://review.cyanogenmod.org/#/c/103272/
Next they introduced a check for strings shorter than 6 bytes because that's the shortest possible valid string. Why not just check for a valid encoding in the first place? There are too many implicit assumptions about the data going on here and not enough actual validation.
This entire module needs scrapping and rewriting with a proper FSM/parser generator.
And why is an MPEG4 metadata decoder directly handling UTF anyway?
The other parts of Android written in C++ are also a horror show, though I think they have gotten better recently.
And don't even talk about the proprietary HAL blobs or kernel modules. Unspeakable things happen there. And of course, libstagefright talks directly to these.
Looks like an instant code smell to me.
EDIT: I appreciate the replies. I was really wondering if I can disable video attachments without disabling other MMS features such as pictures and long messages (in Android 4.3).
The only problem is that many phones automatically turn long SMS messages into a single MMS message. As I understand it, you might not receive those -- although I'm not sure about this.
1. http://review.cyanogenmod.org/#/c/103267/
2. http://review.cyanogenmod.org/#/c/103268/
3. http://review.cyanogenmod.org/#/c/103269/
4. http://review.cyanogenmod.org/#/c/103270/
5. http://review.cyanogenmod.org/#/c/103266/
https://github.com/CyanogenMod/android_frameworks_av/commits...
So. Good luck with a class action suit. You've likely agreed to a contract in which you waived your right to file one. :(
Yes, this sucks. I wish Congress would fix up federal arbitration law.
I bought the Moto X largely on the... assurance ("promise"?) that this particular phone, coming from a Google-owned Motorola, would actually be updated expeditiously by not just the manufacturer but also, downstream, Verizon.
Well, about a month ago my still 4.4.4 phone received an update. FINALLY. Then I looked at the version information; still at 4.4.4 .
I tell you, Google, I'm about done with your mobile products. Not that I hate dealing with them, with Android, but the U.S. (and elsewhere?) ecosphere for them simply sucks.
At least I am at 4.4.4 . Were I at 4.4.3, the last I read I would be subject to a web component vulnerability that Google has refused to fix below 4.4.4 . I suspect there are a lot of phones and tablets stuck at 4.4.3 or below. In fact, my parents have one, a Samsung tablet sold to the by... VERIZON, about a year and a half ago. (And they didn't buy at the cheap/old end of Verizon's tablet offerings.)
I am DONE with this bullshit. Meanwhile, Apple seems to have added some efficiencies to iOS that now allow a 4s phone (not sure about 4) to work reasonably well.
I was staying away from Apple's rather closed ecosphere and attitude. I am seriously reconsidering, at this point. I need my primary phone to fucking work and be reliable. I'll keep the more experimental stuff to other platforms.
Do you have to have the "Hangouts" app installed for this security vulnerability?
Google doesn't seem to have learned from Microsoft's decade of "autorun" problems.
It has been (0) days since the last C language buffer overflow vulnerability.
No. The flaw is present in the extraction of the image data from the MMS message. Anything that uses the system standard way of doing this, including but not limited to Hangouts, will be vulnerable.
Hangouts retrieves MMS messages by default. This can be disabled under Settings => SMS. Turning this off disables the automatic processing and thus the passive exploit, but opening an MMS message containing the exploit can still be done by hand.