
Android libstagefright still exploitable - amatus
http://blog.exodusintel.com/2015/08/13/stagefright-mission-accomplished/
======
stevenh
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?

~~~
ryandvm
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.]

~~~
pokpokpok
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?

~~~
nissehulth
I'm afraid carrier don't care enough to do that. I hope I'm wrong.

------
jimrandomh
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.

~~~
ajross
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?

~~~
semenko
The isolation seems mostly defined by this SELinux policy:
[https://github.com/android/platform_system_core/blob/lollipo...](https://github.com/android/platform_system_core/blob/lollipop-
mr1-release/rootdir/init.rc#L564)

    
    
       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...

~~~
vezzy-fnord
That's not an SELinux policy? That's just a service statement for Android's
init, defining the process' supplementary groups. There is no explicit
seclabel I can deduce.

~~~
semenko
Whoops, yep -- definitely wasn't that clear. As pointed out below, the policy
is linked to:
[https://android.googlesource.com/platform/external/sepolicy/...](https://android.googlesource.com/platform/external/sepolicy/+/master/mediaserver.te)

------
hoopism
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.

~~~
anon1385
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.

~~~
hoopism
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.

------
archmikhail
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...](http://www.extremetech.com/mobile/197346-google-throws-nearly-a-
billion-android-users-under-the-bus-refuses-to-patch-os-vulnerability)

~~~
nadams
> 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](https://source.android.com/source/building.html)

~~~
0xndc
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...](http://www.wugfresh.com/faqs/can-i-still-take-an-ota-after-i-
unlock-and-root/) [2]
[http://www.wugfresh.com/nrt/](http://www.wugfresh.com/nrt/) [3]
[https://developers.google.com/android/nexus/images](https://developers.google.com/android/nexus/images)

~~~
NeutronBoy
> Whoever came up with the idea should be fired, but that's Google for you.

To be fair to Google, once you've modified your /system partition, it's really
case-by-case how an update will interact with it. The alternative is Google
push an update that inadvertently bricks a bunch of rooted phones. Can you
imagine the kneejerk reaction from the internet then?

~~~
nadams
> The alternative is Google push an update that inadvertently bricks a bunch
> of rooted phones. Can you imagine the kneejerk reaction from the internet
> then?

That already happens [1] on non-modified devices. So just come up with a "yes
I know what I'm doing and accept that this may bork my phone". Or and even
better idea - how about the ability to turn off OTA updates? Right now my
phone says there is an update but I can't apply it due to being rooted.

[1]
[http://www.techtimes.com/articles/51525/20150508/nexus-9-and...](http://www.techtimes.com/articles/51525/20150508/nexus-9-android-5-0-2-update-
bootloop-problem-heres-what-to-do.htm)

------
josh2600
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.

~~~
x0x0
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.

~~~
matthewmacleod
_I shouldn 't be required to do to get security releases._

Why should you not be required to do that?

~~~
ocdtrekkie
Because withholding security updates over accepting horrifically invasive UI
and branding changes is unacceptable.

Similar to Microsoft still patching Vista nearly ten years later, Google
should be obligated to deliver security patches to all versions of Android
within a reasonable timeframe.

~~~
oconnor663
I think it's more difficult to patch old versions of Android than you're
suggesting. You can't just backport a few lines of code and hope for the best.
You have to maintain all the testing infrastructure that you had in place back
when that version was supported, to avoid introducing new bugs with your
change. And if you're releasing a security fix, you now have to coordinate
that release across all versions that were vulnerable, because patching the
vulnerability in one version usually discloses it in all versions. So you've
slowed down fixes for your most up-to-date version, on top of the added
expense of all that testing.

Companies like Microsoft make boatloads of money in exchange for supporting
old versions of their software like that. But nobody is going to pay Google
enough to support old Android phones.

~~~
x0x0
it's already disclosed, don't pretend like patching 4.4.4 discloses anything

------
lnanek2
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.

~~~
Dylan16807
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?

------
captainmuon
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).

~~~
CUViper
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...](https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-
Builtins.html)

~~~
captainmuon
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!

------
autobahn
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)

~~~
kyrra
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)](https://en.wikipedia.org/wiki/Stagefright_\(bug\))

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

------
anon1385
>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](https://news.ycombinator.com/item?id=8896221)

~~~
wutbrodo
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.

~~~
anon1385
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).

------
VMG
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?

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

~~~
zurn
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](https://news.ycombinator.com/item?id=7847980)

~~~
acqq
No, overflow is still properly detected by common CPU instructions. There are
flags that are set on overflow after the addition and subtraction and they can
be tested.

It's only hard to test the flags in "standard" C (I don't know if it's better
with newer standards or those in progress) but the CPUs do their work on the
hardware level.

~~~
zurn
But like ploxiln said you now need a conditional branch to test for the
overflow flag after the arithemetic operation, unlike the old overflow traps
on x86/MIPS/Alpha etc.

~~~
acqq
I'm not aware that integer operations ever made traps on x86 and nobody
actually uses floats for allocation sizes (in C). And checking the flag would
be more than enough IF the languages supported it.

It's the languages that should be changed to be able to simply check the
overflow after the critical operations, not the CPUs. The overflow checks are
needed only where something can "go wrong" not everywhere.

------
cautious_int
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.

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

~~~
cautious_int
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.

~~~
Dylan16807
I'm talking about this line

    
    
      uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];
    

size + chunk_size is clearly unsafe to truncate to 32 bits, but it truncates
anyway. When I say 'inside the new operator' I'm including the allocation
function. _Something_ truncates it. If it actually allocated 8GB, or failed to
allocate 8GB, there would be no exploit.

~~~
cautious_int
I was talking about the same line.

Apparently new is a "special" operator, or there is a bug in the compiler. I
also can't get a warning with g++.

The problem seems to be that, as I said, [] takes any integer expression, it
is there where the value gets truncated when operator sizeof or new is applied
on it since they either return or take a size_t value.

------
pacquiao882
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_hearn
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.

------
ikeboy
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.

------
ambrop7
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) .

------
jsingleton
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?

------
RexRollman
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
> 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.

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

------
mondoshawan
[http://www.cyanogenmod.org/blog/more-
stagefright](http://www.cyanogenmod.org/blog/more-stagefright)

Looks like Cyanogenmod has patched this toot-sweet.

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

------
johansch
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).

~~~
redwards510
How do you think jailbreaking is accomplished?

~~~
johansch
Not via the appstore.

