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.
Yeah that threw me for a loop too, I think it's because Hangouts isn't configured to handle SMS for you. Check the Messaging app and its settings. It has a similar disable auto retrieve MMS setting.
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".
There are tens of thousands of extremely skilled hackers selling exploits on the order of $10K to $100K. I'm fairly certain someone has been exploiting it. Not everyone is a good guy in the world.
If you're taking advantage of the law of large numbers, then it's only fair to use it in reverse: There's literally tens of thousands of iphones used by security researchers. One of them would have received a version if this if it was used on such a wide scale..
That's absolutely not true, your certainty is based on a fundamental misunderstanding of exploits and the amount of time and energy required to find them.
I don't see what's "not true" about it. A worm vector of this scale is certainly worth the R&D investment to find exploits, and it is indeed correct to assume that the vulnerability has been found before.
Whether it has actually been used, given the value of the bug, is a different story. But it should absolutely be treated as "in active use" already, especially by state or state-sanctioned actors (like Hacking Team).
What's not true is that this isn't in the wild. Period. You can make all the points about urgency you want and I will agree completely, but this is not currently in the wild, as far as anyone knows. Saying it actually is being actively used would be factually inaccurate based on the information known right now.
But that's the point: as far as anyone knows - more specifically, as far as anyone has admitted.
We do not have a 100% reliable way to determine whether an exploit is known by others (and likely never will have), and as such there is only one reasonable assumption left to make: assume that it is out in the wild and known by others.
This isn't a new concept - threat modelling requires that you assume every worst-case possibility is reality, so that you can guard against it. This was formalized in the 19th century as Kerckhoff's Principle[1], and undoubtedly existed before that in military circles. This applies equally to software security.
So given that we simply don't and can't know whether it is out in the wild, the most 'correct' assumption is that it is - because that lets us protect ourselves against that worst-case scenario, which may or may not be the case.
If you think I'm arguing against the idea of treating the vulnerability like it's in the wild, then you are mistaken. I'm simply stating the fact that no one has any evidence that this is being actively used in the wild.
Are you refuting that fact, or are you not refuting that fact?
The most standout part of this attack (to me) is that it can be 100% silent. The fact that the bug hits before the text notification is fired means that an exploit could potentially stop the notification, delete the message, and go on tramping throughout your phone doing whatever it wants leaving absolutely no indication to you the user that you've been hacked.
Except if the MMS went to an iPhone or other device not affected. Unless you can determine Android/iPhone from just a #, apple/blackberry/MS phones would be full of corrupted MMS messages.
Why would it be corrupted? Just because it contains a malicious payload doesn't mean it has to be unviewable normally. Could even just tack onto all outgoing MMS by default and never raise anybodies suspicions.
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?
We know about the vulnerability, not the payload delivered through it. There could be thousands of them with wildly varying characteristics. There could be none.
Some of them could be rootkits, and have patched filesystem and process explorers to hide themselves. Some could be called virus.exe.
But no, you will never know that you haven't been compromised. In the coming weeks, we may learn about some of the specific malware that spreads this way, and you may be able to test your phone for it, but finding nothing does not mean you haven't been owned by something more exotic.
I don't see where superuser2 said what you attributed to them.
Did they edit their comment between the time you quoted it and the time I posted this comment? Or did HN's quirky rules regarding newlines (gotta put two if you want to display one) change the meaning of your comment?
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?
As a brute-force approach, perhaps you could send the video through otherwise identical patched and unpatched emulators and compare post-playback memory and filesystem states?
It's also probably possible to extend the patches to detect malicious input.
Someone could probably also create a video with a payload to hot patch libstagefright.
This is cool idea. One problem may be that different versions of Android have different versions of libstagefright and just hot-patching that or dropping a replacement may brick older phones.
Here's a more modest idea: Google should immediately issue update for Hangouts and Messenger app that at least disables automatic MMS retrieval. Many users have automatic updates for those apps turned on or maybe at least they'll see a notification about app needing approval to update.
The exploit author told a Forbes reporter that Fennec (Android version of Firefox) has already been patched. If that's correct, that seems to imply two things: (1) MMS is just one of many vectors and (2) apparently somehow the exploit can be mitigated at the app level.
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.
The caveat is that MMS media attachments are not accessible in either the Google Voice Android app, or the web UI. They are (IME) only delivered as attachments to the email copy of the MMS.
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.
Well, given that the exploit has been around for three years, April isn't actually that impressive. I would be more likely to guess that NSA has paid for this 0-day several times trying to prevent it from being released. I don't think that's even a very tinfoil hat scenario. The tinfoil hat scenario is that this exploit was added and ignored at the request of the NSA.
The ability to remotely tap and track almost a billion people with just their phone number? That sure makes metadata valuable...
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).
So the Hangouts bit is just about triggering the problem without user intervention? If an attacker can find another way to get you to play a malicious video, there's still a hole? That's clearly more serious.
It just requires opening the video. The average user will probably open a video from an unknown sender without thinking twice because why would a video message hack their phone. I would imagine given that it controls phones it would also be possible to make a worm from this that resends the video to everyone in the contact list.
What about video in browser? It seems like video is replacing gif everywhere and those autoplay. I've seen websites that have video as backgrounds. Wouldn't stagefright handle those videos also?
> 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.
Certainly not, because the plausible kernel bugs in those open driver descriptors (I'm serious: vendor media drivers are not pretty things) would obviously not be subject to selinux controls.
But at least there is some sandboxing in place; the security architecture was designed to admit the possibility of a breach of the mediaserver.
Link to that reddit thread? AFAICT, all current claims are for a crash exploit into libstagefright, not a breakout of the mediaserver to (for example) persistently write a payload/rootkit.
"The problem is that Stagefright is an over-privileged application with system access on some devices, which enables privileges similar to apps with root access. Stagefright is used to process a number of common media formats, and it’s implemented in native C++ code, making it simpler to exploit
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.
My first-gen Moto X got the 5.1 update about a month ago. Late, but better late than never. Supposedly the rest of the 1st gen Moto X's are getting them "pending carrier support" over the next month or so. Motorola has a website where you can see whether (and supposedly when) your phone will get an upgrade:
Verizon has long been a bastard with regard to releasing updates. However, travel takes me where they are the only thing that works (other than a local carrier that makes no sense back at home). They also tend to have better coverage here at home.
BUT, they told me that one of the selling points of this model on Verizon was that they were committing to releasing updates in a timely manner.
My fault for believing Verizon. But... Google's fault for not pressuring them. iPhones on Verizon get updates. This becomes "simple math", for the user on Verizon. And, Verizon has a lot of users, here in the U.S.
P.S. Even if Google is not in a position to effectively do anything about this, they should recognize the pressure this applies to users to switch platforms. Something I would imagine they ARE interested in.
This is exactly why I won't buy anything except Nexus phones now. The updates are completely independent from the carrier (well, carriers can withhold OTA updates, but you can always flash the current system image from Google).
I'm completely happy with my Nexus 7 2013 (WiFi only).
I may look into jailbreak/rooting options that are compatible with ongoing Verizon service, for the phone.
In future, if I don't switch to an iPhone, I may well go with another carrier, and just eat the cost of e.g. a prepaid Moto G for the times when I travel and need the network covereage. Still, seems ridiculous. And if not Google, the FCC should be taking a good, hard look at Verizon Wireless. At some point, negligence should apply that, if nothing else, gets their spectrum allocations revoked. That would get their attention, fast.
P.S. Maybe a Google lobbyist and/or lawyer could have a quiet little conversation with their FCC contacts about this?
On the flip side, I'm not very happy with my Nexus 7 2013 (LTE, although I never have used it). As a disclaimer I am on CM since 12.0, but even before then there were a number of issues. Tablet would stop recognizing touch or it would inconsistently recognize it; core apps would start to randomly FC; YouTube in particular has an issue where it often would say (and this continued into CM) that there was no Network and you've to press retry 3 or 4 times and then things would work. Hangouts in both regular and CM versions of Lollipop consistently has a bug where switching apps then switching back to Hangouts takes you to a random location in the conversation requiring scrolling back to the bottom frequently. This is an annoying one because there's no way to clear the screen that I've found, you can either delete the entire chat history or you can archive, but the archive is "restored" to the chat window when you begin talking to that person again.
And I apologize, after that rant I realize it doesn't really have anything to do with the topic, but I've sunk the cost already!
To be fair, my Nexus mostly does streaming video and some light emailing and surfing, these days. The display is small but high quality. Netflix keeps prompting me to sign in again, but that seems to be Netflix.
There were some hiccups with the upgrades to 5.x, but I didn't get caught by those. News reports taught me to be a bit conservative, in exercising a bit of delay before applying OS updates if there was no looming security fiasco.
Compared to my parents' contemporary and more expensive Samsung tablet, with Verizon LTE (and thus, Verizon as well as Samsung in the middle), that is still stuck on 4.4.1 or 4.4.2, the last I looked... And with some crappy third party calendar app as the default that had my mother confused for a while...
Well, via that comparison and others, I'm agreeing with the other commenter that if you can go straight Nexus, that seems to be a better way to go WRT the Android platform.
I'm hitting "tired"; otherwise, I might be able to think of some of the software concerns I've had that are not OS / updates specific.
Oh, I remember the time I added some photos to Keep, to learn that there was no way to keep them from syncing while on the cell connection as opposed to WiFi.
And, I could lament the whole "fish around on the web for random articles, for your documentation" approach, these days.
Anyway, I'm mostly responding to show a bit of support, despite our differing satisfaction levels / experiences. When something doesn't work, too often the environment/app leaves us feeling SOL. They got my money, so f--- me! ;-)
I am with you on this. Though I wish running into the arms of Apple wasn't the answer (was really hoping Ubuntu phone would be an option but that is seeming more and more unrealistic).
The fact that the only way to get reasonably-paced system updates is to install 3rd party operating systems (e.g. Cyanogenmod) is extremely frustrating.
If you frequently replace devices, maybe. If you're one of those poor suckers that bought Verizon's version of the Galaxy Nexus, you know that the promise of consistent updates for eighteen months is inadequate.
Not quite 4 years, but well... it still works fine. I wouldn't even expect a current android version, just patches for nasty security bugs like this one. What's so hard about that?
> 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.
According to Moxie[1], TextSecure does not pass media on to anything involving stagefright, unless/until you tell it to open it (which will popup a warning that things are leaving TS's sandbox).
I was just looking at the settings the other day. Per other comments in this topic, I'd look at disabling the MMS features; IIRC TextSecure also has user settings for this.
Edit: Just had a look. I do not have TextSecure as my default client. There is MMS configuration information, but not a simple "disable automatic retrieval" or similar setting, as there is in my default SMS/MMS client. I don't know whether one appears when TextSecure is the default client; I suspect not, and maybe this should be addressed?
Maybe I will make TextSecure my default app. I'll give "the hype" a day or two to start sorting itself, while I have the "auto" stuff disabled in my current default app.
In my -and my lady friend's- experience, TextSecure is the the only app to correctly handle MMS group chat. We tried the stock Android app, the stock Samsung app, and Hangouts. They all failed to do the right thing in one way or the other.
Why can't Google force vendors and carriers in the Play license terms to open source their kernel and flashing technology so XDA and friends can take care of updates?
That would be the cheapest solution.
edit: added benefit, everyone is free to load on his device whatever he chooses. Google should have gone that path way earlier.
This overestimates the negotiating position of Google and underestimates the negotiating position of the manufacturers and carriers.
In the US, the business model for mobile phones is that carriers buy phones from the manufacturer and sell it to the end consumer. The carriers have ultimate influence on what they purchase which affects what the manufacturers produce. You, the end consumer, is a consumer of carriers rather than phone manufacturers.
Well, no Google Android, no phones - Google has a massive stronghold on the market, every consumer wants the latest and greatest phone.
Their stronghold is even enough to prevent ODMs (!) from building non-Play-licensed phones - either you only ship non-play-licensed phones or you ship only licensed ones. No in-between.
> Well, no Google Android, no phones - Google has a massive stronghold on the market, every consumer wants the latest and greatest phone.
It isn't that simple. Although creating a successful smartphone platform from scratch would be very difficult, if enough manufacturers got tired of the terms they might band together are create an app store to rival Play while maintaining Android compatibility. In this case, app developers would only need to change code for in-app purchases, licensing, etc. so a large enough group of manufacturers could draw a significant number of apps to the new store.
> added benefit, everyone is free to load on his device whatever he chooses. Google should have gone that path way earlier.
If Google had required this at the start, Android would never have gotten off the ground. Requiring hardware manufacturers to open source everything would have been a non-starter.
Hangouts has an option under "SMS" to disable automatic retrieval of MMS messages. Can anyone confirm if this at least stops the instant loading of malware?
The real problem here is that video messages expose a huge attack surface to bad actors, very little of which has been security audited.
Automatically parsing videos before the user even chooses to interact with them makes it even worse - although I suspect most people would play a video sent to them over MMS even if it came from an unknown contact.
Now would be a good time for Apple to spread word of this disaster far and wide and to offer a free iPhone to anyone who brings in an Android phone for recycling.
> Now would be a good time for Apple to spread word of this disaster far and wide and to offer a free iPhone to anyone who brings in an Android phone for recycling.
an opportunity for Microsoft too.
Clearly this plus the web-view exploit fiasco will damage the android plate-form for the long run.
Hundreds of millions of devices are affected by this exploit and most of them will never be patched. I'm sorry to say but i'll have to pressure my IT department to ban android devices, period. The problem isn't the MMS tech, the problem is android's lousy security model. And the fact that Google think it can wash its hands off all this and shift the blame on manufacturers... outrageous.
While some manufacturers actually opensource their android 'implementation' (like Alcatel, you can actually download some source code for a specific device and patch it yourself) , most don't even bother doing that.
Absolutely true. It's very clear a platform that can't ensure security fixes in a timely manner doesn't belong in the hands of anyone who handles private data. "Android for Work" isn't much of an option for anyone who values security.
Referenced CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828, CVE-2015-3829 issues seem to still be in reserved status.
From the short description in the article we know that the bug is somewhere in the default video codec paths. (Triggerable by embedded and automatically processed video file.) Of course that doesn't tell much, since the potential attack surface is a big one.
I wouldn't rule out browser as attack vector but I do think the heavy sandboxing at least limits damage and scope. As the article points out, messaging apps are in a different class.
Will be interesting to see how this develops. And because the vulnerability is in the system libraries, any app that can deliver video content may be used as an attack vector.
It's certainly not popular in the UK. It's just too expensive. It costs ~ £0.50 per mms to send so people will just use email / facebook / whatsapp / whatever.
In the US most people are still on a monthly plan that includes "unlimited texts" (inc. MMS). In many other places a single MMS can cost you between 5c-$1, so people use WhatsApp, Google+, or many other free (or cheaper) alternatives.
But MMS is definitely popular in certain regions. It is also very unpopular in regions. If you're in the UK you could very easily disable MMS, but in the US? I wouldn't...
Can you actually disable MMS on Android phones? You can stop the default messaging app from automatically downloading them on my phpne, but I can’t find a way to completely disable them.
Just set you MMS settings to something that looks valid (so the phone will accept them) but non-working. There is then no way it's going to download 'em.
I'm not sure video MMS are popular, but I send a lot of picture MMS texts. Considering it is included on T-Mobile's Simple Choice and doesn't require the recipient to sign up to some service to receive them, it is pretty convenient.
If this issue got bad I might disable it. But it would be unfortunate to have to do so.
Why target people specifically? A phone has all the tools necessary to infect every other peer they can reach. Almost instant billion device botnet, each with a new list of targets to infect in the contacts book. It'll be interesting if this does happen, and the same mistakes as early worms are made (global internet pipe denial of service by probes attempting to find new hosts to infect).
Probably has engineering challenges past what you would normally face, which thankfully makes a 1B device botnet a little unrealistic. I can't imagine how you'd even begin to control such a thing, just a sequential numerical list of the clients is 4GB. Scary prospect though.
Sprinkle in some AES and public / private keys for verification and you're done.
Sequential list isn't needed.
(well, all the robust & stealthy large systems engineering together with the low level exploit knowledge is probably a little too much for one person to pull it off, but for a Hacking Team or nation sized actor it's quite doable)
The bot can call home to ask if/when more infections are desired, so the attack can elastically adapt to remain viable and not overwhelm the resources it needs.
Why bother with a botnet when you already have access to their gmail account. Search for bank emails in their inbox, script a password reset on the account, drain account.
What is the telecom law, if any, on text message delivery? It seems like the first network to announce "we block all stage fright export messages before they hit your phone" would win a huge PR coup (and they'd be able to do so much faster than trying to prep updates for every device they ever sold).
I disabled hangouts on a device I couldn't build from source, then got a constant alert it was trying to start again (Hangouts has unexpectedly stopped notice) so blacklisted it in startup scripts. Google gives you no option to remove it.
When a vulnerability like this becomes public, I always wonder - how many people knew about it before it became public, for how long and how much has it been exploited.
And I also wonder how many more critical exploits are known and used by 'hackers' or agencies today while we have this puffy feeling that our data/communication is private and secure ?
The conclusion I can draw from this: never trust that your phone is secure. Or computer for that matter.
He says it will take a long time for those patches to make it to devices, but I question the validity of the assertion simply because Google has moved more and more into the Play framework. So, unless it is truly a kernel bug I would expect that it's fixable in the framework ore target application.
I heard the radio bit and thought it sounded reasonable. The one explanation that was missing was how this exploit fits in with those apps' permissions. The article makes it sound as though the compromised apps get root, which shouldn't really be possible.
I know this will soon be patched, but would it be theoretically possible to run a root exploit that would root a phone and install a superuser management app? Root your phone with just a text. That would be an interesting exploit.
We're thinking along the same lines. It'd be interesting to root your device while navigating around any voided warranties on the basis of your carrier's, or Google's, neglect (I am definitely not a lawyer.)
AND... could one possibly use this exploit to push their own patch? Could someone who has a payload with a fix mass-message all android users? That payload could also try and send itself to others within the then-patched device's contact list.
This is definitely a huge problem, but I only see it being a doomsday scenario if you're using the default SMS app that ships with your phone (and hence cannot be updated with a patch pushed by your OEM). Assuming you're using Hangouts or Messenger[0] (which is sorta like Hangouts without Gmail), however, as your default SMS app, you should be fine as soon as they patch it. And both of those apps are freely available to download, meaning you could always grab them once they're patched and start using them as your default SMS app if you're worried about it.
Try to convince the average user to install a new app, and make it the default sms app. He will neither want nor understand the trouble of learning a new app for something that works just fine. And honestly, I don't blame them because that is not something they should have to worry about.
Android should rather work on a feature that allows them to patch their not-so-open operating system just like Apple does (or use a concept that is close to the one in the GNU/Linux world but I don't think Google is gonna do that).
This is true, but in the case of Messenger, you should consider the following:
- It's made by Google (i.e. the guys who made the phone's stock SMS app)
- It has nearly identical navigation to the stock "Messages" app, simply with a much cleaner interface
- It does not hook into anything other than your contacts, unlike Hangouts
For all intents and purposes it's the successor to the stock app, made a separate app specifically so that it can receive timely updates without being tied to a system update.
Having used both, there's really no compelling reason not to switch to it (sans the grandma-with-a-smartphone edge case who has never opened the Play Store).
Other comments have mentioned that Hangouts is not the only possible attack vector, but I'll be honest in saying that I don't really understand all this. :)
Well technically Android runs Linux (the kernel) too. But Ubuntu can be updated. My HTC Android phone only had a single update (almost when I got it) and it's been vulnerable since.
I'm not going to replace my phone each time there's an exploit that the manufacturer doesn't fix. So I don't think an Ubuntu phone would be such a bad idea.
HN does prefer original sources generally, but breaking stories like this one often produce articles with additional reporting as they develop. So it's not obvious that the original post has the most relevant information at this point. If someone wants to figure out which URL does, we can change the HN thread to use it. It's currently pointing to the npr.org story rather arbitrarily, but perhaps that's as good as any.
It's annoying that the media continues to incorrectly spin Android's security updates problem as somehow caused by its open ecosystem (which itself barely meets the definition of open) and implying that Apple's closed system is the solution.
GNU/Linux distros are free open source software, and don't suffer from these sorts of update problems. Many distros have special high-priority security update channels that are enabled by default.
Please, call this out if you have friends writing / spreading such nonsense.
> It's annoying that the media continues to incorrectly spin Android's security updates problem as somehow caused by its open ecosystem
That isn't "spin". Android's ecosystem is (largely) controlled by the phone carriers in this context. Their "open" system is a fractured jumble of closed systems with indifferent maintainers.
If Google took it up, Apple's method here would be a solution. Were Google to force carriers into supporting security updates on Google's terms, we wouldn't see this kind of issue.
Nobody making the Android/iPhone comparison in this context cares about "openness". That's largely a foregone conclusion on both devices. They care about the effective and timely distribution of security updates.
> GNU/Linux distros are free open source software, and don't suffer from these sorts of update problems.
Why on earth would NPR compare Linux distributions (which the general public has basically never heard of) to smartphones? It might be "more accurate", but it's not an accessible comparison.
> That isn't "spin". [then some correct statements, but not relevant to spin]
See also my other comment about words having false connotations, regardless of intent.
> Nobody making the Android/iPhone comparison in this context cares about "openness".
I don't know why you just assert this so nonchalantly. Clearly some people care, because they keep repeatedly associating closed systems with security update mechanisms, even though we have plenty of open systems with relatively good security update mechanisms. That is in fact my whole point; other people keep veering off on a tangent.
> it's not an accessible comparison.
What is "accessible" is very transient, dependent on the environment and cultural background. Those of us who are interested in balance and accuracy, have to make it accessible. Not doing so is irresponsible.
Um... I don't think the article in question does this. It seems to describe the issue accurately: Updates are dependent on fixes being pushed out by device manufacturers and network carriers.
"Android phones are very different from iPhones, for example. Apple runs a closed system. It controls the hardware and software, and it's fairly easy to ship out a major revamp. The company says 85 percent of iPhone users have the latest operating system, iOS8."
The fact that Apple runs a closed system is not relevant to Android having poor security updates, as is evident by how GNU/Linux distros work - yet these things are mentioned next to each other, as if they are related.
(edit: lots of people missing the point here. media articles can equally point to free open source software GNU/Linux distros as having relatively successful security update mechanisms, yet Apple's closed ecosystem is always given more focus as the contrasting example to Android's; why? it is not the closed property that makes a security update mechanism succesful, yet that is the implication.)
(edit: this is how weasel wording works; statements of fact which may be individually correct, are placed together in suggestive positions, so that the non-cautious reader walks away with a false understanding of a more complex point, but allow the author to deny responsibility of this)
Other media articles have similar weasel wording. I'm not commenting on the author's intent - e.g. they may just be repeating the dominant narrative on this - however the wording has misleading connotations regardless of intent.
You still haven't made a case for that being wrong.
This isn't that hard:
Bug in iOS:
1. Apple releases a patch
2. All users of supported devices can install it
Left hanging: people with old devices (minimum age approaching half a decade)
Bug in Android:
1. Google releases a patch
2. Many Nexus users can install it immediately
3. Everyone else has to beg dozens of manufacturers to ship an update for a device which brings no further revenue to the hardware manufacturer
4. At least in the U.S. everyone then has to beg carriers to ship an update to existing devices rather than using this as a chance to push you to upgrade to a $$$ new device and extended contract lock-in
Left hanging: everyone who doesn't own a recent Nexus device. Minimum age: negative – devices without the current OS will be sold to users months after release.
Note that absolutely none of this is Android's fault technically. It's only Google's fault to the extent that they naively believed everyone else would be responsible and neglected to have this license require updates, unlocking after dropping support, etc.
> It's only Google's fault to the extent that they naively believed everyone else would be responsible and neglected to have this license require updates, unlocking after dropping support, etc.
Otherwise known as "entirely their fault". It was very evident that this would be the case, as it was always the case before. Left to their own devices, OEMs and carriers will not approve updates because they simply don't care and have zero motivation to.
It happened with Treos, Nokias, and BlackBerries. It didn't happen with Apple because they used their clout to strongarm carriers into playing by their rules, and they are the OEM.
Google deliberately went buddy-buddy with the carriers to saturate the market as much as possible in response to the iPhone, and the concessions they made to do so are part of the reason Android devices still have this problem.
There was absolutely no reason to assume that anyone would "be responsible" if left to their own devices. It was not naivete, it was a calculated tradeoff to grant carrier control over user security, to give carriers a reason to promote Android over iOS. Google did a lot of things right with Android, this was not one of them.
infinity0's point seems to be that a more fair reporting would be: (1) here's the problem with Android's ecosystem [was included] (2) here's the solution with Apple's ecosystem [was included] (3) here's the solution with OSS distros' ecosystems [was NOT included]
I think it's fair to take umbrage that an intelligent but uninformed reader could very easily walk away from that article with the conclusion that "If Google ran Android more like Apple runs iOS, then Android would be more secure."
Which itself is probably true, but far from the only solution. And indeed, probably the least free (speech) solution.
I understand the argument but it's very weak because open source projects have the same fundamental problem and we have something approaching two decades of security problems caused by it. The underlying challenge is that anyone can ship a copy of something without making a binding commitment to ship updates.
Point 3 is only true if you cherry-pick “OSS” to mean “People who installed Red Hat, Ubuntu, Debian, etc. themselves and religiously install updates”. OSS also includes things like the various forks and boutique distributions which started drifting behind, all of those insecure libraries where someone installed a copy of OpenSSL, libtiff/libpng/etc., or almost any PHP app, and never came back to update it.
This problem is only going to get worse as the IoT gold rush continues and all of these “Two EEs and a web developer” companies ship a device shortly before folding, being bought out, etc. and there's no indication to the customer when it's no longer safe to have that device on a network.
Note that this isn't saying that open-source is insecure – the same problems routinely happen with commercial software, too – but rather that it's not a magic wand for solving the problem. Apple ships updates promptly because their reputation depends on it, which is the exact same mechanism which keeps Debian, Red Hat, Ubuntu, etc. going, too, but that approach doesn't work in the case where the real customer isn't the person using the device. As long as Samsung keeps Verizon happy, they only care about the user experience to the extent that many people would choose to buy another not-Apple device instead of theirs.
Ultimately, I think we really need legal changes to ban corporate attempts to shirk liability for flaws in their products and sharp restrictions on the ability to prevent users from securing their own devices – something like a vendor being required to publish the full source, build toolchain, hardware unlocks, etc. if they go more than a couple months without releasing a patch for a known problem in a particular device.
This is my big irk: Shirking liability. Google, and it's fans, spend a lot of time blaming everyone else for the problem. It's the OEM's fault, or it's the carrier's fault. It's dozens of other companies fault that Android is insecure. But nobody wants to hold Google liable for developing a platform that they distribute in a manner that is completely insecure.
Google sets the terms by which it does business with OEMs. And yet, they've never been held to blame for the bad experience that users get due to this model. Google uses these terms to protect it's monopoly dominance, by mandating OEMs install 20 or so proprietary Google apps, but not to do anything really valuable to the customer, like mandating a security patching methodology.
> Ultimately, I think we really need legal changes to ban corporate attempts to shirk liability for flaws in their products and sharp restrictions on the ability to prevent users from securing their own devices – something like a vendor being required to publish the full source, build toolchain, hardware unlocks, etc. if they go more than a couple months without releasing a patch for a known problem in a particular device.
Agreed, and imho this is in practice where Android differs from OSS as I referred to it.
Worst case, if you're running a non-Redbuntianwarint distribution, then you still have much better access and separation between components. Admittedly in practice almost no one avails themselves of the ability to build from source. But that's not the point.
The point is that someone can do so, and distribute that to others if they want it.
With Android, that prospect on {random device X} gets a lot more tenuous. Either because there are hardware security locks to prevent you from doing so or because there are missing or unavailable pieces that are included in the official manufacturer/carrier's build.
Great comment. Who now is liable for the damage caused by hacking Android phones with this vulnerability — Google, manufacturer, carrier, or the user?
Perhaps as we get more physical hacking events that are easy for the media to cover, companies will start taking this seriously. If so, I'll guess that Google will assume that responsibility in exchange for more Apple-like control over the update process. There's no other sane way.
My instinct is that liability should go to whoever you paid: if you bought a phone from Verizon, they should be responsible for the device and do whatever they need to with the vendor without involving you in the process. If you buy the phone directly from Samsung, Motorola, etc. they're responsible and should negotiate appropriately with Google for the support they don't want to do in house.
Most of the problem is that the general cycle for Android is a decent base OS which has two levels of middlemen adding cruft to it mostly for marketing reasons and that's as bad as it is because they're only looking potential income. Not letting them dodge liability changes that calculation in favor of either not obstructing the update process for branding reasons or, if they really think their custom UI is such a great selling point, actually hiring enough people to support it reponsibly.
They don't mention (4) here's how Microsoft solves this in Windows, or how Tesla solves the problem, either, and I don't think they need to. This text is about the problem of updating a billion phones, not of updating all other kinds of stuff.
I don't see how they would have to cater for what their readers infer from this text about open source at all, as I can't find any way they even suggest that Android is open source.
The only reference to 'open' I can find in the text is "open an attachment or download a file that's corrupt.". The closest I can find to "Android is open source" is "Google gives its latest version of Android to manufacturers, and they then tweak it as they please.".
I think anybody who makes the jump from that to 'they can tweak it because Android is open source' also knows enough to not make the further jump to 'open source is dangerous'.
> 3. Everyone else has to beg dozens of manufacturers to ship an update for a device which brings no further revenue to the hardware manufacturer
> 4. At least in the U.S. everyone then has to beg carriers to ship an update to existing devices rather than using this as a chance to push you to upgrade to a $$$ new device and extended contract lock-in
The solution is for Google to pay manufacturors (or share revenue, however you want to put it) to update all existing phones:
- Google is accountable for shipping the bug. They should pay the costs.
- Google is currently taking almost all the profits. Android phone makers, as we've all read, are running on thin margins, if they aren't losing money. The media stories that say Apple makes 95% of all mobile profits fails to include Google's profits.
Google not doing this is, IMHO, an ethical breach and putting profits before users greed. What shinratdr said.
Not there aren't issues that get through (like this one, I believe), but you forgot:
1a) If the issue can be fixed and/or worked around in Play Services, Google does that and "everyone" gets the fix without even having to explicitly install it.
3b) For each OEM, if the problem can be fixed/worked around by updating the apps and/or frameworks they publish via the Play Store, they do that (if only for the sake of new and upcoming devices) and all of their customers get it once they install those update.
Those cover a large (and growing, because Google and the OEMs are both aligned on this) chunk of your "left hanging" users.
It's true that there are sometimes workarounds but they're only relevant to certain cases. This bug appears to be a good example of why you can't rely on being able to fix most or even the most severe ones with that approach.
#3b is particularly optimistic since that assumes an OEM will ship updates promptly and that's been the underlying problem here since day 1. It particularly wouldn't help if, say, a vendor ships an update for their flagship Android 5 devices which doesn't run on the 4.x devices which most all of their users have and will never receive an upgrade to Lollipop.
> Everyone else has to beg dozens of manufacturers to ship an update for a device which brings no further revenue to the hardware manufacturer
I wonder why do the manufacturers even lock the phones if it brings no further revenue. They lose nothing if users where able to pull the updates directly from Google.
> I wonder why do the manufacturers even lock the phones if it brings no further revenue.
Because a Google update that conflicts with their own customization and borked the user experience would cost them future revenue, since it would reduce the chance that the user would by a phone from them in the future.
It is relevant: Apple's system is closed against meddling by lazy middlevendors as well as against the likes of us. If Apple decides that you should upgrade (or not) there's little Deutsche Telekom or Verizon or any other middlevendor can do about it.
That it's closed against us is not nice at all, but being closed against Deutsche Telekom and Verizon and such is a feature, not a bug.
How is that 'weasel wording'? That's an accurate statement of fact. The article never calls Android 'open' and doesn't blame the issue on the openness of the ecosystem.
The issue is described fairly accurately.
It would however be nice if the article brought up the point that the issue could be mitigated if users were allowed to actually control the software that runs on their phone (without hacking around restrictions). Instead most users are reliant on the device manufacturing seeing the financial incentive to provide updates.
> Instead most users are reliant on the device manufacturing seeing the financial incentive to provide updates.
Most users are reliant on this regardless. Few people possess the technical ability, much less time, to perform these tasks. Making the platform "open" and pointing to that as a solution would also be a way of weaseling out of that responsibility to users.
The number of people who could use a fairly simple third party to to update their operating system on their phone is much, much larger than the number who can figure out how to obtain root access or unlock their bootloader using a technique that varies depending on exact model number and firmware version.
Obviously there are users who will be left behind, but that is an issue for novice users of ANY free and open source software.
In practice, the situation is not directly comparable to Linux distros; Android vendors produce closed Android forks for each phone, and update these seldom and late. If someone was doing this with Linux distros, they'd be similarly nightmarish, security-wise.
Certain distributions may not have the exact same update problems, but Linux as a whole sure as hell does, being free and open source fixes nothing by itself. The inherent insecurity of an abandoned OS over time is one of the largest issues with the whole Internet of Things device trend.
I both heard the story this morning and read the article, and the intent didn't sound to me (admittedly, and obviously from participation here, as someone in the tech industry) like it was open vs closed, but more Apple's ability to immediately address issues that arise like this are a result of their closed nature, but with Android's open policy, everyone from Google to HTC|Samsung|LG to Verizon|Sprint|AT&T get to touch the code, and because of all these modifications, it will be a while for a fix if one even comes. If anything, the lack of financial incentive to fix anything was more the culprit over openness. The worst part is none of it was opinion - that's all completely true. How many phones get maybe one update after being released to the wild?
I agree with a precise interpretation of what you are saying, but I think you are focusing on the wrong problem. The real problem is that Android really isn't an open ecosystem.
Then you didn't read the article; it's a video handling bug; the article notes a difference between Hangouts and other messaging apps in video handling which makss it worse with Hangouts, but the fundamental problem is with video handling, not the messaging app.
On the radio they mentioned that a phone's standard messaging app would be vulnerable the moment it downloaded the poisoned video file (prior to the user watching it).
>GNU/Linux distros are free open source software, and don't suffer from these sorts of update problems
Agreed, but I would go further and say that the _PC platform_ doesn't suffer from such problems. You can buy a computer from HP/Lenovo/Toshiba/whatever and later buy an OS upgrade from Microsoft. Ordinary users can do this.
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.