Android libstagefright still exploitable

http://blog.exodusintel.com/2015/08/13/stagefright-mission-accomplished/

by amatus • 11 years ago

164 142 11 years ago

blog.exodusintel.com

josh26002• 11 years ago

Did I read that right? They reported the bug to Google on August 7th and disclosed it publicly on August 13th?

Is this still responsible disclosure if they give Google basically 6 days to respond and use the original notification date as justification? I'm not learned enough in the practice of responsible disclosure to know if this is common, but I've not seen that before.

jimrandomh2• 11 years ago

It isn't a new bug; what they're reporting is that the patch which was supposed to fix an already-publicly-disclosed bug doesn't fully fix it.

josh26002• 11 years ago

Can you help me understand this? They're complaining about a bug in the patch implementation and the patch implementation did not exist prior to the patch; ergo, if Google didn't patch the code, they wouldn't be able to write the article.

Is that not a new bug almost definitionally? Please help me understand if I am incorrect.

I understand the underlying issue which was first reported did not get patched properly, but, if someone found a bug in the heartbleed patch today and disclosed it immediately with the original patch date as justification, I would imagine many would be screaming bloody murder.

x0x03• 11 years ago

Eh, fuck google. They still haven't patched the original stagefright for android 4.4.4 on my nexus 5, and I don't want to upgrade to android 5, which I shouldn't be required to do to get security releases.

ocdtrekkie10• 11 years ago

Same problem. My options for my Droid Turbo are suffer Android 5.x or get a Windows Phone.

...I'm getting a Windows Phone.

matthewmacleod2• 11 years ago

I shouldn't be required to do to get security releases.

Why should you not be required to do that?

archmikhail• 11 years ago

Even if Google patches this, there's an incredible delay in getting the patch to users. Android in fundamentally flawed in this respect.

http://www.extremetech.com/mobile/197346-google-throws-nearl...

kreutzwj2• 11 years ago

Agreed.

There is a major issue, not sure if in the rest of the world, but in Canada, the service provider has to request, and commonly pay for, the patch to which the manufacturer completes and then the service provider then pushes out to their devices. At least that is how it was when the E911 issue happened, it may be better now, but knowing Telecoms in Canada, I wouldn't be surprised if it wasn't.

canistr• 11 years ago

It's not better. Look at the proposed target released dates for StageFright patches by Telus. And considering that it is not even fully patches, this only adds to the insanity of the situation with regards to Android fragmentation and carrier's controlling releases.

http://forum.telus.com/thread/54211/category/top/board/Mobil...

  OEM	 	Model	 	        Target Release
  HTC           One M7	 	        August 14th
  HTC	 	One M8	 	        August 14th
  HTC           One M9	 	        August 14th
  HTC           Desire 320a	        August 28th
  HTC           Desire 601	        August 14th
  LG	 	Nexus 4	 	        Completed
  LG	 	Nexus 5	 	        Completed
  Motorola	Nexus 6	 	        Completed
  Samsung	Galaxy S5	 	August 11th
  SamsungGalaxy S5 Active	 	August 11th
  Samsung	Galaxy Alpha	 	August 21st
  Samsung	Galaxy Grand Prime	August 21st
  Samsung	Galaxy S6	 	Completed
  Samsung	Galaxy S6 Edge	 	Completed
  Samsung	Galaxy S4	 	August 28th
  Samsung	Galaxy Note 3	 	August 30th
  Samsung	Galaxy Note 4	 	August 11th
  Samsung	Galaxy Core	 	September 4th
  Samsung	Galaxy Tab S 8.4	September 4th
  Samsung	Galaxy Tab S 10.5	September 4th
  Sony	 	Xperia Z3	 	August 14th

lumpygravy• 11 years ago

Indeed. Even the supposedly quickly updated Moto X did not receive a patch yet two weeks after the fact [1]. I feel sorry for all those people who are still stuck on Kit Kat or even worse Jelly Bean.

https://www.reddit.com/r/MotoX/comments/3gugxa/anyone_got_th...

ocdtrekkie10• 11 years ago

And for those of us who don't want Lollipop, we'll never be offered the update. We have to either accept a bad system "upgrade" or stay insecure.

nadams5• 11 years ago

Even if Google patches this, there's an incredible delay in getting the patch to users.

I don't think delay is the problem - not being able to get or apply the patch yourself is the problem. Ignoring the somewhat ridiculous requirements to compile Android (200GB of HD space and 16GB of RAM [1]) - you couldn't put it on your Android device due to proprietary drivers for wireless and/or video.

Assuming you can get an updated version - I have noticed that after getting root on my Nexus 6 it won't install new versions of Android. I don't know if it's a by-product of getting root/installing a new recovery or if they have an actual check. I have a legitimate reason for root because I use FreeOTP and it does not have an export feature - so I use Titanium backup to backup and restore the app. Getting the OTP QR codes for: dropbox, gmail, Microsoft account, facebook, srchub, github, paypal etc would take a very long time and considerable effort to recover (hint gitlab).

[1] https://source.android.com/source/building.html

SamReidHughes3• 11 years ago

I don't think delay is the problem - not being able to get or apply the patch yourself is the problem.

Almost all users would be incapable of applying patches themselves.

jeffreyparker• 11 years ago

Regarding exporting OTP settings: My solution was to use Titanium Backup on the Google Authenticator app, extract secret keys from that data, use them to create GA-compatible setup QR codes for each account, and save those QR codes in KeePass.

You could likely do something similar with FreeOTP, once that's done you can easily restore your codes without root. (And from then on be sure to save any future setup QR codes you use.)

0xndc• 11 years ago

It's a check - as of Android 5.0, Google's OTA updater scripts refuse to overwrite your /system partition if its checksum isn't on the known-good list. Rooting inevitably involves writing files to it, so OTA updates will stop working with an uninformative "Error!" in recovery. Whoever came up with the idea should be fired, but that's Google for you.

See [1] for details from the author of NRT [2], which can update your phone from factory images without wiping it. The procedure is a bit more involved if you're not on Windows - IIRC, you have to download the correct archive from [3] and modify the update script so it doesn't try to flash userdata.

[1] http://www.wugfresh.com/faqs/can-i-still-take-an-ota-after-i... [2] http://www.wugfresh.com/nrt/ [3] https://developers.google.com/android/nexus/images

AUmrysh• 11 years ago

This was one of the big motivating factors for me getting a nexus 6 (aside from the size) and putting it on the fi network. I got 2 updates in the period of a week.

I think the problem is vendors and carriers wanting to modify and inject their crapware and custom UIs into Android. Google is happy to provide upgrades to the OS in a timely fashion (and are going to start monthly updates), it's the vendors/carriers that delay these updates or don't even bother to port them over to devices.

Google is moving much of the core Android functionality over to specific apps that they can update as needed from the play store, instead of integrating them directly into the OS. This is good, because it allows them to push the updates quicker. They run the risk that carriers will get sick of the lack of control over the "experience" they can provide, and fork android, but it's a necessary step in many ways to ensure things like this MMS exploit can be patched on some devices at all, as vendors abandon some phones quickly, leaving users vulnerable.

If every vendor and carrier used stock nexus android without modification, the updates could be pushed out in days. The linked article blames google for these problems, but that is, in my opinion, misguided.

anon13853• 11 years ago

Deadline exceeded – automatically derestricting The flaw was initially reported over 120 days ago to Google, which exceeds even their own 90-day disclosure deadline.

It always seemed likely that Google's hubris[1] would come back to haunt them. I guess this is that day.

It would be funny if it wasn't remote code execution affecting 950 million phones, with no official patch in sight.

[1] https://news.ycombinator.com/item?id=8896221

kyrra2• 11 years ago

They have become a bit more flexible[0] after the Windows issue. They are still living by the 90 day policy, but baked in some flexibility if the vendor is communicating with them.

[0] http://googleprojectzero.blogspot.com/2015/02/feedback-and-d...

wutbrodo• 11 years ago

Wait, either I'm grossly misunderstanding the article, or you are. The flaw the author is talking about is one that Google has been aware of for six days... Not 120. The original bug from 120 days ago was already patched.

We're essentially talking about a bug in the bugfix, which obviously hasn't existed as long as the original bug itself. I'm really not seeing where "hubris" comes into this.

anon13853• 11 years ago

That's the logic the blog author is using. As you can see in the bit of the article I quoted. I didn't say I necessarily agree with their analysis of this still being the same bug.

The fact that they mentioned it a couple of times suggests it was a factor in their decision to release the details today (or at least wanted to poke fun at Google).

jimrandomh2• 11 years ago

Summary: A little over two weeks ago, it was publicly disclosed that 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. Today, Exodus Intelligence is reporting that the patch to fix one of these vulnerabilities does not, in fact, fix it. Thus, all Android phones are still vulnerable.

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. If you have not done so already, this is urgent. Furthermore, you should assume that auto-downloading of MMS messages will not ever be safe, no matter how many individual security fixes are applied, until this component of Android is significantly re-architected.

pacquiao8823• 11 years ago

This specific exploit can be initiated whenever metadata for an MP4 file is processed. Disabling auto-download of MMS is an important first step workaround. Be cautious with any untrusted media files on your Android device. Simply creating the thumbnail preview image is enough to silently trigger privileged code execution.

ajross2• 11 years ago

I'm still unclear on the sandboxing assertion. The mediaserver in current versions is, in fact, pretty well isolated. I've had to work around and defeat lots of this protection for debugging purposes in my professional life, so I know it's there. IIRC you can't read system or app data outside the sdcard area, you can't write anywhere persistent. You can open network sockets and make binder requests, which is not trivial but again rather different from a remote root.

That this is an exploitable bug in libstagefright seems to be uncontested. But AFAICT there are no assertions of an actual sandbox breakout or a practical payload that does something more than e.g. send spam. Are there? Link?

semenko2• 11 years ago

The isolation seems mostly defined by this SELinux policy: https://github.com/android/platform_system_core/blob/lollipo...

   service media /system/bin/mediaserver
       class main
       user media
       group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm
       ioprio rt 4

You'd need another exploit to elevate from SELinux (and I think send MSSes for a self-propagating worm). Though given Android's abysmal patching, most Android kernels are also terribly outdated...

rcheu• 11 years ago

The original bug was demoed with another privilege escalation exploit, it wasn't clear which one was used. See https://www.youtube.com/watch?t=64&v=PxQc5gOHnKs

guelo2• 11 years ago

I believe mediaserver also has microphone and camera access which seems scary, though I don't know what harm a crook could do with it. Spy agencies might be more interested.

In general though I totally agree, the media hype has been irresponsibly overblown.

hoopism2• 11 years ago

Is this timeline correct?

April 2015 - Original stagefright exposed

July 31st - Author noticed patch was not sufficient but could not test (did not notify google)

August 6th - Patch released

August 7th - Author notified google that patch was not adequate

August 13th - Author went public?!?!

They are counting the original date of exploitation as the start date for notification. I would think a more responsible and friendly date would be August 7th. Just me.

anon13853• 11 years ago

I sympathise with your point, but one complicating factor is that when big security vulnerabilities like Stagefright are found a lot of people then turn their attention to that code. Either finding other issues in the same code, or that the patch isn't fully effective. It was similar with Shellshock, where there was a series of patches as more issues were found because suddenly people were looking at this bit of code that had previously been uninteresting.

I'm not sure keeping it secret for long serves much purpose in this kind of situation; the eye of Sauron is already gazing on the code in question. I doubt these people were the only ones to notice that the patch didn't completely fix the problem.

hoopism2• 11 years ago

That's fair.

Perhaps I am more alarmed by the assertion of the author that they had given 100+ days notice... it came off like they talking about the patch and not the original issue.

MichaelGG• 11 years ago

OTOH, it's highly likely that other people already found this. So by disclosing now, they are still helping users by making sure they don't think this bug was fixed.

But they shouldn't try to justify it based on the timelines. Especially if they noticed a bug in the original patch, but held off on saying anything.

At the same time.... It's business. They didn't act maliciously (exploiting or selling the exploit to bad actors). If the way to build a career is to rack up CVEs, well then that's what people will do, right?

danielweber3• 11 years ago

I sympathize, but there weren't enough details for Joe Random to build an exploit. This was an attempt to apply pressure, and it did it in the right way, by telling people how they can defend themselves.

Unlike Shellshock which was all over the freaking place, neither I nor my colleagues have gotten any suspicious MMS messages.

mike_hearn4• 11 years ago

How would you know? A well written exploit would immediately hide the notification of itself.

mzs• 11 years ago

My last line would be:

August 13th - Still no response from google(!), disclosing publicly.

Basically that's integer type overflow, the moment I saw the four line patch, I knew what it was going to be. Everyone else would see that too cause it's a classic and can modify whatever exploit code they already have in a matter of minutes to work again.

I have a nit too. I don't like the term "responsible" used in this context. I prefer coordinated if anything. The responsible as in responsible disclosure is such a loaded term.

By the severity and simplicity here as well as the attention from the recent talk, this was a fine course of events in my personal opinion.

What I wish would have happened is someone at google would have done a better code review and caught the bug, it's pretty glaring as these things go, but still it happens all the time so considering that the patches were simply applied the next option I wish would have happened otherwise is that someone at google would have responded. In a case like this I would have liked to see a day or two at the most.

But none of that happened and considering the other concerns laid-out in the post, releasing the info publicly after almost a week is pretty responsible.

gionn• 11 years ago

So, a security engineer, working at Google, cannot catch that a 4 lines patch is ineffective?

johansch3• 11 years ago

Things like this is why I trust an iPhone enough to handle two-factor auth for banking (in Sweden: "Mobil BankId"), but not an Android device.

I hope Google will raise the security level now that they have reached global dominance, in no small part through lax security (as a consequence to their liberal licensing models).

andrewguenther• 11 years ago

Right...

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-12...

matthewmacleod2• 11 years ago

That's a bit silly though, isn't it? The iPhone has had quite a few major RCEs over the years.

autobahn2• 11 years ago

because somehow magically an iphone is more secure because reasons?

I agree that iphone's patching model is superior to android, but your statement shows a bit of ignorance.

johansch3• 11 years ago

Because they have a working patching model, yes.

redwards510• 11 years ago

How do you think jailbreaking is accomplished?

johansch3• 11 years ago

Not via the appstore.

bitmapbrother5• 11 years ago

This is not a pretty picture: http://www.cvedetails.com/product/15556/Apple-Iphone-Os.html...

And before you nominate Apple for security sainthood, let's not forget the bruteforce / unlimited password attempts hack on iCloud that allowed hackers to get ahold of sensitive pictures belonging to celebrities.

caffeinewriter• 11 years ago

Security through obscurity is no security at all.

lnanek2• 11 years ago

Doesn't seem very responsible behavior by the reporter. Google accepted the suggested patches, fixed the original cases. Now some other cases are discovered for these larger numbers, OK, that seems like a new thing to fix next. Not sure why I have to read paragraphs of hate when the company put the suggested patches in already. Seems like just an excuse so they can ride the page view wave.

Dylan168074• 11 years ago

This doesn't seem hateful to me, and the problem is that google took so long to fix anything at all on top of barely caring about the fix. Why not fuzz the fixed version for 10 seconds?

jsingleton• 11 years ago

There was an Android update pushed to my phone recently. I wanted to know if it was an urgent security fix so I checked the diffs. It's hard to tell but it doesn't seem to be. It's a bunch of fixes to do with video out, SIP etc.

I thought maybe the patch fixed this security flaw. It wasn't clear what it was for from the phone. I had to do a fair bit of digging. Are there any change-logs or release notes for these system updates?

captainmuon3• 11 years ago

And I was wondering at the beginning of the article why they were doing

    if (SIZE_MAX - chunk_size <= size)

and not the more readable

    if (size + chunk_size >= SIZE_MAX)

Of course, C integer overflow. The real WTF is that this is possible in C.

What would be more sensible than integer overflow would be to automatically promote integers to a larger type in the context of a comparison, so that they don't overflow. I wonder if you could add that to the language in a backwards-compatible way? Maybe add a new builtin (compiler-specific, but shared by popular implementations?) like

    if __no_overflow(x + y > z)

that would make the addition of two ints become long, two shorts become int32, and so on. (Two long longs would internally become BigNums, but that wouldn't be exposed.)

And while we're at it, add a __checked(a+b) construct, that sets a flag if overflow occurs (or maybe raises an assertion - or maybe we should have both options).

CUViper2• 11 years ago

You seem to be asking for quite some magic in that __no_overflow idea. It might be possible with a trivial expression like this, but what if there are function calls in that expression, or even library calls? There are lots of places overflow could happen, and the site of your __no_overflow may not have code-gen control over it at all.

As for __checked, gcc has some builtins like this: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

captainmuon3• 11 years ago

Well, it wouldn't reach into functions. It would mainly just change the + and - operators within its scope to return a larger type. So instead of

    int32_t plus(int32_t left, int32_t right);

the plus operator would be equivalent to

    int64_t plus(int32_t left, int32_t right);

So basically

    int32_t a = 2000000000;
    int32_t b = 2000000000;
    int64_t c = __no_overflow(a+b);
    // now c is 4000000000;

I don't claim the idea to be flawless or completely thought out, but I believe something like that could be one of the more useful C language extensions.

Oh, and thanks for the link!

pacquiao8823• 11 years ago

The bigger issue of libstagefright is that it there's a ton of code involved with media playback at the native level that has access to many system resources. This specific exploit was just looking at a small part of the MP4 handling -- one of the many parts within the library. It is very likely more severe exploits like this one will surface as a result of this huge library.

mike_hearn4• 11 years ago

It's a bit surprising because so much of Android is written in Java. Given hardware decoding of the video itself I wonder why Stagefright needs to be written in C++ at all. Media processing code has been notorious for being exploit ridden for years, so it's not like this problem was unpredictable.

VMG• 11 years ago

Why are arithmetic overflows and underflows not exceptions/crashes by default, like divison by 0?

Aren't the cases where you actually want an over/underflow the exception? Why not resort to special instructions/macros/operators for these operations?

CUViper2• 11 years ago

Rust debated this for a while, and eventually did decide to make overflows panic -- but they are checked only in debug builds.

https://github.com/rust-lang/rfcs/blob/master/text/0560-inte...

ploxiln• 11 years ago

Performance. That's an extra branch on every arithmetic operation.

zurn3• 11 years ago

There's a performance cost now because processor instruction sets have dropped hardware overflow detection due to disuse. Current processors are largely engineered to just run legacy C code fast. See eg. https://news.ycombinator.com/item?id=7847980

barrkel• 11 years ago

That's not how you'd implement it if you had a choice though. You'd rely on a certain page of memory not being mapped on the target platform (the page that starts at address 0 is often a fine choice) and you'd issue a conditional move that touches that address. You'd rely on the CPU exception interrupt mechanism to branch.

I know modern ARM instruction sets don't have conditional instructions like that, but they may have something similar for extremely infrequently triggered control flow. The same kind of trick can be handy in a variety of programming language and GC implementation techniques.

captainmuon3• 11 years ago

You could actually have runtime checks by default (in a hypothetical language), and have a smart compiler elide them whenever possible.

    int32 a, b = ...;
    a+b; // there is a check
    // implicitly:
    // if (MAX_INT32 - a <= b) throw OverflowException;
    // a+b;

but

    int32 a = ...;
    // after here: typeof(a) = int32
    int32 b = rand_int(0, 1000);
    // after here: typeof(b) = int32[x|where x >=0 and x < 1000]
    if (a < 500) {
        // in here: typeof(a) = int32[x|where x < 500]
        a+b; // the overflow check can be elided
    }

So the compiler would be able to narrow down the type of a variable, and know what operations are safe to perform. This is probably impossible in the general case (halting problem and so on), but I believe it is very doable if you restrict yourselves to a limited number of subranges. This is like a kind of dependent types, but completely internal (you could expose them, if you wanted though).

The compiler can't only use this extra information to remove overflow checks, but you can also have a language that guarantees there is no overflow - add two int32 and the result is an int64, and so on. And if it can infer that the result fits in an int16, then it can put it in there. But most of the time you would just use int, which means: integer variable of enough length to store my data. int8, int16, int32, maybe a BigNum. Kind of like python does it, but with the ability to pick optimized native types if needed.

cautious_int4• 11 years ago

Because unsigned overflow will not happen in C, and will instead wrap the value. The variables in question were unsigned.

This is defined and perfectly normal.

However signed integers will cause undefined behavior on overflow and there is a common flag in most compilers to trap on overflow.

ikeboy• 11 years ago

Can carriers (and by extension, the Hangouts backend itself) check messages and block "evil" ones? Wouldn't that be an easier way of fixing these things quickly?

At the very least, Google should block any Hangouts message that triggers the bug even on non-updated devices.

autobahn2• 11 years ago

Just to give everyone a bit of calm, nobody's demonstrated a successful exploit with ASLR bypass.

Meaning that while the vulnerable is technically exploitable, the chance of system compromise is very low on modern android phones (I think post 4.0)

kyrra2• 11 years ago

Per the wikipedia article[0] ASLR (address space layout randomization) was first added in 4.0 and fully enabled across the OS in 4.1. To go with that, 91% of android phones are on >= 4.1, and 95% are on >= 4.0 [1].

[0] https://en.wikipedia.org/wiki/Stagefright_(bug)

[1] https://developer.android.com/about/dashboards/index.html

stevenh• 11 years ago

Any competent malware developer must have already figured out how to exploit this the first time around. Now that every single one of those malware developers has learned it is still exploitable, the payload they've spent the past month perfecting can now be deployed in the wild.

So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten minutes of being released in the wild?

1. Text payload to victim

2. Payload executes on victim's phone and texts itself to all of the victim's contacts

3. Repeat

Assuming the average Android phone owner has 20 contacts who also have Android phones, and assuming also that texting the payload to those 20 people would take two minutes to complete, the infection would spread exponentially and only take ten minutes for the initial text to result in the infection of 10 billion devices worldwide.

Why am I not currently being bombarded with MMS video texts from infected devices? It frankly seems a bit miraculous. Did Google set up an emergency arrangement with all of the carriers to block suspicious video texts so this wouldn't happen?

mike_hearn4• 11 years ago

Apparently the exploit doesn't work on devices that have good ASLR (based on a /. comment by someone who works on the Android security team).

danielweber3• 11 years ago

1. Maybe it's not as easy as you think.

2. The MMS system isn't as anonymous as the Internet and someone didn't want to burn an identity making this worm.

3. A combination of 1 and 2, where the people with technical skill to do this would only use it on specific targets.

guelo2• 11 years ago

Because, despite the hype, the bug doesn't give full root access to the phone.

m3rc2• 11 years ago

Didn't a number of texting apps, possibly including hangouts, update to fix it separate of this botched fix?

EDIT: I just checked and sure enough my texting app, QKSMS, updated to remove the Stagefright library

bitmapbrother5• 11 years ago

No, apps cannot remove system libraries responsible for processing video. What your MMS app did was disable the auto-retrieval of MMS messages.

djb_hackernews• 11 years ago

From what I've read, and could be wrong, is you could be infected and not even know it. The attacker has the opportunity to "clean up" the MMS so you never even get a notification because the bug is before any of that kicks in.

bentcorner• 11 years ago

Still, we'd see a bunch of reports from non-Android phones receiving MMS's from infected Android contacts.

ryandvm• 11 years ago

It's not often that Android's fragmentation is touted as a benefit, but the fact that Android isn't a monoculture is certainly one of the hurdles to developing a worm capable of mass deployment. Supposedly the varying implementations of the Android media services mean a libstragefright exploit may or may not end up with root access.

Now, if this were an iOS zero-day exploit...

[Actually, it'd be trivial for the carriers to filter the payload, so I don't reckon SMS/MMS is ever going to be a viable transmission vector.]

nissehulth2• 11 years ago

Yes, I believe the payload have to be tailored pretty much exclusively for each type of device. But, I doubt that would stop anyone trying. Company phones are often the same type and model, someone with a certain target in mind could probably put in the hours.

pokpokpok• 11 years ago

do carriers already have a mechanic in place to trigger precautions a message matching worm-like patterns (similarity, mass transmission)? or would they have to implement one after it's too late?

acdha• 11 years ago

I suspect the answer is something like this:

1. A worm would be highly visible and easily blocked by carriers

2. There's no easy way to make more money from a mass worm than you could make from lower-profile, more-targeted attacks. You could ask a billion people to send you a dollar but that'd leave a paper trail anyone could follow.

3. The more widespread it is, the more pressure there is on vendors & carriers to ship patches for old devices

bitmapbrother5• 11 years ago

So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten minutes of being released in the wild?

There are a couple of reasons:

1) Just because you have an exploit it doesn't guarantee you'll be able to execute code because you still need to bypass ASLR. The PoC's released do not do this.

2) Infecting phones with malware is very rare. The "tech pundits" like to scare the public, but the reality is that smartphones are rarely infected. Besides, the people that write and distribute malware are too busy infecting Windows machines.

NateLawson2• 11 years ago

Correct, most malware infections of mobile devices are targeted attacks for espionage etc.

dmitrygr• 11 years ago

With selinux (as most android phones 4.4+ have) I imagine an exploit is not possible.

NateLawson2• 11 years ago

The carriers are already blocking messages that match this pattern. That's why you haven't seen widespread exploitation.

https://twitter.com/jcase/status/628327791713517570

However, this only works in the US when you have 6 carriers. I have no idea what the situation is like elsewhere with massive carrier fragmentation.

ambrop7• 11 years ago

I think the proper check is:

// size_t size; // uint64_t chunk_size;

if (chunk_size >= SIZE_MAX - size) { return ERROR_MALFORMED; }

Due to size being a size_t and SIZE_MAX being well a maximum size_t, SIZE_MAX-size is properly calculated. The comparison with chunk_size is also properly done (due to the C promotion rules - as strange as they are, they do work "as expected" when your values are nonnegative, which they are here).

Also, I am slightly puzzled why one would use SIZE_MAX as a limit rather than some "small" number, like a few megabytes or whatever is a reasonable bound for this buffer. In this case the fix may be a bit more complex than this: if (chunk_size >= SIZE_MAX - size || size + chunk_size > the_limit) .

RexRollman2• 11 years ago

IMO, the Android echosystem is a clusterfuck and Google needs to get a hold of it. I would buy a Windows phone before I would buy an Android device.

chimeracoder• 11 years ago

IMO, the Android echosystem is a clusterfuck and Google needs to get a hold of it. I would buy a Windows phone before I would buy an Android device.

This is nowhere near as bad as the situation with Windows XP 10 years ago.

The difference is that Android has the majority marketshare worldwide and Windows phone does not, making Android the more attractive target both for researchers and malicious actors.

Security by obscurity is not entirely without value, but it's not particularly strong as a defense either.

RexRollman2• 11 years ago

I think it is worst. As least with XP, you didn't have Dell preventing you from getting a security update.

cautious_int4• 11 years ago

This is a common problem in C. Integer types are inherently type unsafe and are silently promoted with many different rules which are hard to remember and understand. As is seen in this case, even the ( borderline paranoid ) flag -Wconversion would not catch the bug.

I think this problem in C would be solved with a single flag: -Wwarn-if-using-integers-of-different-types-in-an-operation , forcing you to cast the integer if the types don't match in a arithmetic operation, or an assignment.

Dylan168074• 11 years ago

I can understand the comparison passing, but why in the world does nothing warn about the truncation inside the new operator?

cautious_int4• 11 years ago

Because no truncation happens. In this case [] operator doesn't specify any type, only that the expression inside is an integer expression. While normally the type size_t is used for object and array sizes, [] takes any integer expression and the compiler won't complain.

mondoshawan• 11 years ago

http://www.cyanogenmod.org/blog/more-stagefright

Looks like Cyanogenmod has patched this toot-sweet.

Android libstagefright still exploitable

Related Stories