Farewell, Stagefright bugs!

Tsukasa OI
a4lg.com
2015-09-09
Japan Android Group | Regular Meeting, September 2015
Farewell, Stagefright bugs!
What the hell were these vulnerabilities? / What we can find from this confusion?
[ENGLISH : version 1.2.1]

Caution for English Viewers (1 of 2)
• This session (talk) is held at Tokyo, Japan in
September 9, 2015 (only in Japanese)
• As a part of a regular meeting of
Japan Android Group, an Android user group in Japan
• Main audiences were non-security engineers
• This is not written for hackers
• This is English translation of version 1.2
• Includes fixes and additions from version 1.0
• In most cases, I write slides in both languages at the
same time (for better “localization”) but... not this one.
• The slides may include many mistranslations
• Sorry because I don’t have much time to
review/correct my translation now

Caution for English Viewers (2 of 2)
• This is written for Japanese audiences
• There are many references to Japanese articles
(with no translation to English)
• Includes many Japan-specific information
• For instance, MMS is not even available on most
Japanese mobile careers (except SoftBank)
• Approximately only 13% of Japanese Android smartphones
can receive MMS messages
• So, information in the slides may not
apply to your country!
• Remind it and be careful!

Introducing Myself (1 of 2)
• Tsukasa OI (大居司; @a4lg)
• An independent security researcher
• A speaker at Black Hat Abu Dhabi 2011 / USA 2012
• Specialty: Low-layer architecture
• In mobile OS research, I was researching
how mobile OS security is built on
and how we could exploit the security mechanism.
• I also research higher layer of mobile OS
(because it was necessary).

Introducing Myself (2 of 2)
• Tsukasa OI (大居司; @a4lg)
• An independent security researcher
• A speaker at Black Hat Abu Dhabi 2011 / USA 2012
• Mobile OS Research at FFRI (-2014)
• Android
• Fundamental Android security documents written in Japanese
such as “Inside Android Security”
• Pointed out that Android 4.0’s ASLR is not perfect and made
patches to fix this issue (Google already fixed though – internally)
and written the first Android 4.1 ASLR article in the world
(written in Japanese so not known outside Japan) 1
• Windows Phone 7.x
• Fundamental research about exploitability and security
analysis of Windows Phone 7.x OS (Mentioned as “Research by
trusted third-party” by Microsoft Japan in ads2)
1. https://ja-jp.facebook.com/notes/455931517757936
2. https://www.microsoft.com/ja-jp/windowsphone/products/merit/security/default.aspx

In this talk
• Playback the whole story about
so called “Stagefright” bugs
• Enlighten what are Stagefright bugs
from technical perspective
• Find what was so wrong about news reports
regarding these bugs
• Find what should we learn and what are
obstacles we are facing

The Playback
What the hell has happened?
How should I talk about this?

The Playback (1 of 5)
• 2015-07-27 : Android vulnerabilities discovered
by Mr. Joshua J. Drake (@jduck), Zimperium
(zLabs) in April and May 2015 have announced 1
• Vulnerabilities in a common component in Android
• Named “Stagefright”, the same name as
the vulnerable component [disambiguation needed]
1. https://blog.zimperium.com/experts-found-a-unicorn-in-the-heart-of-android/

• Many news reports described how grave they are
• They affect Android 2.2-5.1
• They enable remote code execution in app privileges
• They can be exploited only by sending an MMS message
• Disabling MMS is countermeasure
• They affect more than 90% of Android devices
• Could cause one of the biggest security updates
• But, many news reports had “issues”
(text in red has issue [more or less])
• A Japanese article I “infuriated”:
95％のAndroid端末にMMSを受信するだけで端末を乗っ取ら
れる脆弱性が発覚、対策はこれ – GIGAZINE 1*
• A few “issues” remain unreported
1. http://gigazine.net/news/20150728-android-hack-stagefright/
• Title roughly translated from Japanese to English: “Vulnerability which 95% of Android devices are compromised only by
receiving an MMS message discovered; This is the countermeasure – GIGAZINE”

• 2015-08-05 : Proof of concept video by Zimperium
is released but might be misleading
• Not only taking reverse shell (by malicious MMS),
this demo does root the device.
• Without some knowledge, we can easily
get wrong messages from the video.
• At least, there’s a few point to take care
if this video is watched by non-hackers...
• Google and Samsung to release
security updates over the air, monthly
• Sounds good (but can others follow?)

• Around 2015-08-17 : A few weeks after
Black Hat USA, slides by Mr. Drake have released
• Written very carefully and sincerely
• Some technical points I thought I discovered first
already mentioned by him
• In general, this talk looks very good
• But most of Japanese media missed
many important points
• Besides, some media didn’t even write an article
based on his talk in Black Hat USA
1. https://www.blackhat.com/docs/us-15/materials/us-15-Drake-Stagefright-Scary-Code-In-The-Heart-Of-Android.pdf

• 2015-09-09 (09-10 in Japan),
working exploit by Mr. Drake is published
• CVE-2015-1538 #1 (‘stsc’ chunk)
• Full ASLR bypass on Android 4.0
• Independent analysis and attempts to exploit
will go on...

I’m going to talk about...
• What is Stagefright?
• What is so called Stagefright bugs?
• What was wrong in the code
• Possible attack vectors
• Possible effects
• Resolving confusions:
• What was wrong in the media?
• Was MMS really grave (and serious) in Japan?
• Others (a few topics)
• Security updates in Android
• Possible solutions? (examples)

The Basics
Stagefright and the media processing

What is Stagefright anyway?
• Stage fright [noun]
→ nervousness felt by a performer or
speaker when appearing before an audience.
• Easy to misspell as Stage flight?
• That’s not what you looking for (I believe).

What is Stagefright? (1 of 3)
• Common framework to define interfaces
to handle media elements (sound/movie)
on Android (libstagefright and other)
• Came in front in Android 2.2-2.3*, replacing existing
open source software OpenCore
(specifically developed for Android)
• Extendable by OpenMAX (OMX) IL components
• Default software decoders/encoders are implemented
as OpenMAX IL components
• Provides common interfaces
(encoder / decoder / metadata retrieval)
* Appeared in Android 2.0 (in source code level) and a choice of media framework in Android 2.2, default in Android 2.3.
* By the way, Mr. Drake mentioned that two Android 2.2 devices have Stagefright enabled but in my research,
two Android 2.2 devices (I have) didn’t enable Stagefright.

• Common framework to define interfaces
to handle media elements (sound/movie)
on Android (libstagefright and other)
• Actual processing of media is performed on
external libraries
• Software processing example : FLAC [libFLAC]
• Hardware processing by custom OMX IL components
• Stagefright core library bridges underlying data
structures and parses metadata
• Used in Android
• But that wasn’t the end...

• Also used in Mozilla Firefox (including PC)!
• Of course, shared same sort of vulnerabilities
• However, modified from Android’s Stagefright
• So status of the fix is not synchronized
• Main parts are fixed in Firefox 38.0
• Did some of them fixed independently?
• A vulnerability which may not be used to run
arbitrary code (still leads to DoS) is not fixed yet
• Today, we are looking Android Stagefright
* One of the PoC files published by Zimperium (crash demo) crashes Firefox 40.0.3.

Media Processing in Android (1 of 3)
Example: while playing music using MediaPlayer class
libstagefright.so (common interface)
3rd party OMX
HW (e.g. VPU)
Stagefright sublibraries
external libs (e.g. libvorbis)
external libs
(e.g. libFLAC)
Outside Stagefright matters!

• Many “privileged” operations are performed
inside service in separated process in Android
• Media-related operations are handled by
“mediaserver” process (MediaPlayerService)
• Inter-process communication via Binder
• “mediaserver” runs on “media” user
(with other GIDs [will talk later])
• Misunderstanding of Vulnerability:
Successful attack takes application privileges
• In this attack, buffer overflow occurs in “mediaserver”
process (separated from the application)
• As a result, successful attack takes “media” user and some

Example: while playing music using MediaPlayer class
(roughly in reverse order of call stack)
app_process (the application process)
Application implementation
…
android.media.MediaPlayer class
libmedia.so (Media Library)
mediaserver (media processing service)
…
libmediaplayerservice.so (Media Player Service)
…
libstagefright.so (common interfaces)
3rd party OMX
HW (e.g. VPU)
Stagefright sublibraries
external libs (e.g. libvorbis)
external libs
(e.g. libFLAC)
* After “rendering” by Media Player Service, basically “Audio Flinger” in the same process or
“Surface Flinger” (separate process) will actually “play” the media file.
Binder
(IPC)
Vulnerable here!

The Vulnerability (1 of 2)
What kind of vulnerabilities discovered by Mr. Drake?

Analyzing Patches (1 of 2)
• 12 patches by Mr. Drake
Patch Vulnerability Type Possible Consequences Caused By:
1 NULL-pointer dereference Crash Insufficient state management
2 NULL-pointer dereference Crash Insufficient state management
3 Division by zero Crash Insufficient validation
4 Buffer Overflow Memory Corruption * Integer overflow
5 C++ Exception Crash Use of exception-throwing “new”
7 Buffer Overflow Crash / Infoleak Integer overflow
9 Buffer Overflow Crash / Infoleak Invalid handling of strings
* Vulnerabilities with possible consequences of “Memory Corruption” may be used to run arbitrary code.
Some may be difficult due to lack of attacker’s control but note that some of Stagefright components run in parallel.
* “Infoleak” doesn’t necessarily mean leak of information to hide (also means pointer leak which may be used for ASLR-bypass)

Analyzing Patches (1 of 2)
• All grave vulnerabilities are caused by
integer overflow...
• There are other fixes but difficult to run arbitrary
code (or impossible)
• What is buffer overflow caused by
integer overflow?
• Note : Can occur, regardless of signedness
(this time, all Stagefright bugs are unsigned type based though)

Integer Overflow and Flaws (1 of 3)
• As a result of integer arithmetic,
the result may not fit inside the resulting type.
• In case of C/C++ (signed 8-bit integer [-128〜127*]):
• Actual behavior is undefined!
(You may get -128 but that’s only a coincidence)
• Actual behavior may be defined on other languages
0 1111111127
0 00000011
+ 128 1 0000000 (-128) ?
Exceeds representable range
?
Behavior is undefined
* This example is based on two’s complement representation but the behavior is undefined regardless of internal representation.
(Interesting thing: C specification does constrain internal representation but C++ specification doesn’t)

• As a result of integer arithmetic,
the result may not fit inside the resulting type.
• In case of C/C++ (unsigned 8-bit integer [0〜255]):
• Overflown bits are discarded
(Equivalent to modulo of 2^
8 = 256 in case of 8-bits)
• Behavior is defined (but the result may not be safe)
11111111255
000000011
+ 1 00000000 (256)
00000000 0
Overflown bit
... is discarded

• Integer overflow in buffer size calculation
may directly lead to buffer overflow
• Did you write such code?
size_t sz;
if (fread(&sz, sizeof(size_t), 1, fin) < 1) goto error;
int *buf = new int[sz + 4];
// ...
• Some sz causes integer overflow in (sz + 4)
• If sz is SIZE_MAX, (sz + 4) equals 3
• Other than explicit arithmetic: e.g. casts
• Actually, C++ code above has another integer overflow
other than addition (depends on C++ specification and environment) *
• Depends on implementation but may lead to
grave buffer overflow
* Answer: See “The Extras” section

Buffer Overflow for Beginners (1 of 2)
• Redirect the program flow by controlling
how the memory is corrupted
• Example: Classic stack-based buffer overflow
• Because describing heap-based overflow is much harder...
Array (buffer)
on the stack
If buffer overflow occurs,
“return address” and other
data are overwritten!
Return
Address Others
Call history (stack):
Subroutine
A
Subroutine
B
Overwritten by the attacker!
Array (buffer)
on the stack
Return
Address Others
Attacker’s
Code
Subroutine
B
“Subroutine B” is called by “Subroutine A” but
replaced by attacker’s code
(it means, Subroutine B “returns” to attacker’s code)

Buffer Overflow for Beginners (2 of 2)
• To bypass mitigation techniques like
Data Execution Prevention (DEP), some use
fragments of existing code to attack
• Example: Classic stack overflow with ROP
(Return-Oriented Programming) to bypass DEP
Array (buffer)
on the stack
Return
Address Attacker’s Code
The attacker cannot run this
code because of DEP
Array (buffer)
on the stack
Return
Address
Return
Address
Return
Address
Return
Address
Executable
Module
(in-memory)
Choose useful address in
executable module in
the memory
Gadget
4
Gadget
3
Gadget
2
Gadget
1
Subroutine
Perform “attack”
by concatenating gadgets

One Vulnerability Details (1 of 2)
• Integer overflow while processing ‘tx3g’ chunk
• MPEG-4 chunk for subtitles
• Important Note:
If multiple ‘tx3g’ chunks are appeared,
the contents are concatenated
• Let’s discover the vulnerability!

One Vulnerability Details (2 of 2)
• Integer overflow while processing ‘tx3g’ chunk
chunk_size : (attacker-controlled)
MPEG-4 chunk size
mLastTrack : MPEG-4 track processing
case FOURCC('t', 'x', '3', 'g'):
{
uint32_t type;
const void *data;
size_t size = 0;
if (!mLastTrack->meta->findData(
kKeyTextFormatData, &type, &data, &size)) {
size = 0;
}
uint8_t *buffer = new uint8_t[size + chunk_size];
if (size > 0) {
memcpy(buffer, data, size);
}
// ...
Prefix subtitles processed
(append new subtitle later)
Integer overflow!
Buffer Overflow!
(with attacker-controlled size)
* In this vulnerability, buffer may overflow twice (usually once; depends on data source).
We are looking beginning part of buffer overflow and common cause of both buffer overflows.
Quote from Android 4.4 (r1) : frameworks/av/media/libstagefright/MPEG4Extractor.cpp

The Proof
Some may have fun, some may have fear.

Before the Demo...
• I cannot perform live demo (sorry!)
• Because I targeted Android 4.4, placing payload
depends on luck (may take more than an hour)
• So, I prepared videos
• In “The Proof” section, I want you to
confirm attack vectors
• Later, we see what we can do using the payload
placed in the demo.

Demo (1 of 2)
• Via: MMS
• Cancelled!
• SoftBank line wasn’t stable enough and my exploit
in development were very unreliable
(so I failed to take video of successful attack)
• I sometimes hate that I live in a countryside...
• I targeted Android 4.4 so it wasn’t a pure MMS attack
but with another vulnerability to bypass ASLR

Demo (2 of 2)
• Via: Web browser
• Download executable file and runs
on memory (not using exec!)
• Nexus 5 + Android 4.4.0 (r1)
• Some demo on Android 5.0.0 (r1)

The Vulnerability (2 of 2)
What we can/could do with Stagefright vulnerabilities?

Attack Vector
• Everything can be attack vector
if it involves Stagefright
• Man-in-the-middle (Mobile Optimization)
• Watering hole attack (to existing web sites)
• To trap web page
• Media attachment in MMS
• Android Malware

Effects (1 of 2)
• The attacker takes privileges of “mediaserver”
• Basically no access to application-specific data but...
• This process has many privileges for
media processing!
• GID: inet
Remote-control via the Internet
(the reason why remote shell’s taken in Zimperium’s demo)
• GID: audio / camera
Full control of microphone / camera
• Others (e.g. Bluetooth-related)

Effects (2 of 2)
• The attacker takes privileges of “mediaserver”
• Basically no access to application-specific data but...
• This process has many privileges for
media processing!
• Service in the same process : AudioFlinger
Full control of the speaker
• Also, it has direct access to related devices
(depends on device but higher risk to rooting)
• Some devices have much danger privileges
• ... as Mr. Drake says (see his presentation for details)

Mitigation? (1 of 2) : SEAndroid
• Enhancements to SELinux by NSA etc...
also targets Android Binder and more
• Added in Android 4.3
(with Permissive mode with no enforcements)
• Enforced in Android 4.4
• SEAndroid should stop privilege escalation but...
• Required privileges are already permissive enough
• Exploiting kernel vulnerabilities will bypass
SEAndroid completely (depends on the device)
• In Android 4.4, policy is virtually not enforced on the
mediaserver domain (Permissive + Unconfined)
• Better policy on Android 5.0

SEAndroid @ Working (a bit)
• Looking Android 5.0 Policy...
• Cons:
• Neither Permissive or Unconfined (policy enforced)
• Shell : not possible to run (using execve)
• One of the necessary permission, execute is missing (target: shell_file)
• Mediaserver has execute permission for certain tools (target: system_file)
but not executable (because of lack of execute_no_trans* permission)
• Self-writable files are not executable
• Not even loadable as a shared library (mmap is restricted too)
• Pros:
• Permits execmem* to itself
* execute_no_trans permission specifies whether source domain can execute another file without domain transition.
For example, many shell tools are better to be run under the same privileges as origin and
execute_no_trans specifies such behavior (if domain transition occurs, permissions “transition” and “entrypoint” are required)
* execmem permission specifies whether the process can make writable memory region executable.
Lack of this permission makes JIT unavailable but it also makes easy to prevent mprotect used by attackers.
Some regions are checked using permissions “execstack”, “execheap” (brk-related region) and “execmod”.

Mitigation? (2 of 2) : ASLR
• This case, reliability of the attack can be reduced
by ASLR (Address Space Layout Randomization)
... or can it?
• Added in Android 4.0 (and advertised as a security feature)
but incomplete this time (2 executable modules are fixed)
• Full ASLR is enabled on Android 4.1
• Memory layout is intentionally randomized every run
実行 1
実行 2
実行 3
The attacker must have very
specific control to the memory but...
Pointing specific address (in white)
is... pretty hard here

ASLR @ not working (so well)
• Not possible to avoid
• Using other vulnerability, leaking memory pointers
• If mediaserver crashes, it restarts immediately and
some applications do not crash by this,
enabling attackers to perform “brute-force”
• The reason why Web-based attack succeeded
• ASLR has an implicit premise:
“If an attack fails, the next attack is
impossible or discontinued”
• In this case, failure of an attack is not easy to spot and the attacker
can repeat the attack while ASLR is bypassed
• ASLR safety basis is... broken here

Closing : Technical Stuff
• Many attack vectors
• More than single application privileges
• Including full control of camera, microphone and speaker
• Many mitigation but...
• Depending on the attack, it cannot “mitigate”
the attack (as you think this is safe) (SE+ASLR)
• Practical attack is possible after successful exploit,
without depending other mitigation (SEAndroid)
• I wanted to show you a bit different perspective
than Zimperium’s demo

The Confusion
Confusions in news reports
(what we all should have learned)

Confusion in News Reports
• Many confusions in news reports
• Possible reasons
• Ignorance of reporters/medias
• Principal difference of perspectives between
normal people and security engineers
• Insufficient “localization”, lack of considering
local situations
• MMS, known as “the” attack vector caused
confusions because of above all three reasons
• In this section, we need to look...
• Before that, there are some other topics

Issue (1) : Effect is App Privilege?
• Possibly caused by impression of effects
caused in the similar system
• Some news websites, such as Engadget Japanese 1
spread this misunderstanding
• Shame on me, I first misunderstood like that
• If Stagefright directly runs on the application,
the primary effect is limited inside the application
(still, it’s serious enough)
• Actually, successful attack effects privileged
process so effect can be large and systemwide
• Attacking app with no camera permissions
will get attacker camera control, for example
1. http://japanese.engadget.com/2015/07/27/android-95-mms/

Issue (2) : Removing Traces
• Some news reports mentioned that
the attacker can remove traces (MMS history)
• Possible (maybe) but it’s (at least) not generic and is either:
• Device-specific
• Result of using multiple vulnerabilities
• “media” user is not “root” or “system” so basically
“mediaserver” cannot control whole Android user system
• Still, Mr. Drake noted that “mediaserver” in some devices
have “system” GID (not strictly equivalent to “system” UID but
very close)

Issue (3) : Privilege after MMS attack
• Some news reports also mentioned that
the attacker can get higher privileges,
specifically after MMS attack
• Maybe, this is a mistranslation of his slide:
“SILENT, REMOTE, PRIVILEGED”
• If attack succeeds, the privilege doesn’t
change by attack vector

Issue (4) : Disabling MMS? (1 of 2)
• Conclusion (and precondition):
In Japan, disabling MMS is not an effective
mitigation and attack vector remains after that
• Look at the title (note: roughly translated)
• Vulnerability which 95% of Android devices are
compromised only by receiving an MMS message
discovered; This is the countermeasure – GIGAZINE 1
• What would happen if the reader doesn’t actually
read the article carefully? ... That’s clear.
• Second to last paragraph is fixed by my complaint to the media
but flashy title didn’t fixed...
• Did you think this can only occur in “tabloid medias”?
No, that’s not the end...
1. http://gigazine.net/news/20150728-android-hack-stagefright/

Issue (4) : Disabling MMS? (2 of 2)
• Many news media (including infosec medias)
mentions that disabling MMS is a mitigation
• But, it may not work nice in Japan (“localization” matters!)
• More than that, ONE attack vector, MMS,
is focused too much!
• MMS is “much serious” (I agree)
(Differences of perspectives)
• But, focusing ONLY on this is not good (even outside Japan)
because the image of the attacker is trivialized
(reporters missed what to tell to the normal people + α)
• There was only one Japanese famous source 1
mentioned the attack vector of Stagefright bugs
“correctly”, “comprehensive” and “well-balanced”.
1. http://blog.trendmicro.co.jp/archives/12060 (the Japanese translation of http://blog.trendmicro.com/trendlabs-security-
intelligence/mms-not-the-only-attack-vector-for-stagefright/)

MMS : What is MMS anyway?
• (3GPP/OMA standard) messaging service
for mobile phones, surpassing SMS’s restriction
• Supports SMS-style submission to “phone number”
and submission in “mail address” format
• Inter-career communication isn’t strictly standardized and
it depends on cooperation between careers,
so some combinations may have some restrictions
• Supports attaching media files
• Including MPEG-4 movies
• Notified by special kind of SMS
(How the device process this SMS specifies how to retrieve)
• Such SMS-based remote control / notification is
used on some protocols (including MMS)

MMS : MMS in Japan
• Docomo : NOT SUPPORTED (including iOS)
• au (KDDI) : SUPPORTED ONLY ON iOS
(no MMSC set on KDDI Android devices)
(MMS app [Hangout] is not installed by default)
• SoftBank : SUPPORTED
• This “mitigation” does absolutely nothing
other than the user use SoftBank
• This mitigation is not so “working” in Japan
• Other attack vector remains
• tripleshot1 says... (translated by me)
We can also say, “in Japan, MMS-receivable Android users are only
8% of whole Japanese smartphone market” (very arbitrary!)
1. http://tripleshot.hatenablog.com/entry/2015/07/28/222103

MMS : Why this vector so focused?
• Because it doesn’t need user interaction, at all
• For most of attack vectors, the attacker must fool
the user and let the user trapped
• Or, the attacker must work hard to let this attack working
• MMS can be sent without users’ consent and
the attack works when auto-retrieval is enabled
so very useful for attackers
• Version 3 of CVSS1 , Common Vulnerability Scoring
System includes “User Interaction” to score
vulnerabilities without user interaction
1. https://www.first.org/cvss

MMS : Focused, too much
• Still, this attack vector shouldn’t
necessarily focused too much
• In general, we must focused on all major attack
vectors to take countermeasure to the vulnerability
• However, the MMS is not the all major attack vector,
even outside Japan
• Note that differences of perspectives:
“normal people” vs. “security engineers”
• Security engineers naturally focus on MMS.
...That’s fine.
• Except ... that is not everything to protect users
from the threat.

MMS : Looking Back
• Mitigation needs localization (at least)
• “Localization” is not just translation!
• Local situation should have been considered
• Focus on the attack vector remaining after mitigation
• Never give users “false sense of security”
• Attack vector should be focused
much comprehensively
• Focusing one too much makes losing other
• Should security engineers and medias work together?

The Future
How can we do?
There’s no answer but... there ARE some examples.

More than 90% of Android devices
• We can never ignore it
• Note that common framework is vulnerable
• Many of “serious” Android vulnerabilities are caused by
vendor-specific customization
• Easy buffer overflow in the driver
• Badly written backdoor for vendor support application
(which malicious user can exploit)
• Will the device upgraded?
• Security update is not guaranteed on Android
• Such issue is in iOS (and most of Apple products) too

Android : Monthly Updates?
• Google and Samsung to provide monthly
security updates over the air1
• Also, they are going to guarantee support lifetime
• This is purely great
• Clear support lifetime
In 3 smartphone OS, all other than Windows Phone
have unclear policy of support lifetime
• Periodic updates
Avoids delay (due to include security update to
other kind of update [to save OTA money])
• However, applying this policy to “all” vendor
can cause a problem...
1. http://jp.techcrunch.com/2015/08/06/
20150805google-and-samsung-will-now-release-monthly-ota-android-security-updates/

Android : Update Hell for OEM
• Pre: providing upgrade is a role of manufacturer
• Of course they are responsible but...
• Too much cost/responsibility for manufacturer!
• The manufacturer should compile everything in Android
(despite some parts can be shared between devices)
• Example: Linux distributions for ARM
other than hardware-specific and arch-specific ones,
the package file can be shared in binary level!
• Manufacturer needs to handle all security upgrades
(including ones they’re not basically responsible)
• I think this problem can be (partially) solved by
cooperation between Google and other third parties

Binary-Common Userland
• Arch Linux ARM on...
• Raspberry Pi 2 Model B
SoC : Broadcom
• USB Armory
SoC : Freescale

Modular Updates (1 of 4)
• Divide system layer
(package common and specific parts separately)
• Make them upgradeable, independently
• Vendor-specific issue is not fixed but
reduce cost to upgrade common parts
Android device
Kernel (Type A)
Common oem.ko Common
userland
OEM
specific
Some kernels will be needed
because of hardware differences
Package everything and
enable independent upgrades
* This figure is only a hope... But I think this is (partially) possible

• Example : Windows Phone (7-8)
• Core parts are completely controlled by Microsoft
and manufacturers will only get OEM privileges
• Updates are modular
• However, some updates are controlled by
mobile careers, not by Microsoft 1
• Example : Windows 10 Mobile (planned)
• Microsoft is going to control nearly everything1
1. http://www.zdnet.com/article/microsoft-says-its-taking-over-updates-for-windows-10-mobile-devices/

• Example : Ubuntu Touch
• I haven’t analyzed this yet but
• Mr. Michael Hall at Canonical says: 1
• The system is now well layered into multiple layers
• They are able to update the base system layer
without interfering with the OEM layer
1. http://news.softpedia.com/news/ubuntu-touch-support-will-be-provided-as-long-as-technically-possible-488449.shtml

• Of course, there are some down sides
• Weak vendor lock-in to hardware
Example : Windows Phone (depends Qualcomm)
• How do they focus on the chipset?
• Not a problem... mostly.
• Limited customization
• Android has some hardcoded values in the system
• So, current design may not be suitable for better customization
• Vendor-specific issues are vendor-specific
• Many vendor-specific security flaws
(e.g. recently, Certifi-gate 1 found by Check Point researchers)
1. http://www.itmedia.co.jp/enterprise/articles/1508/07/news064.html

The Conclusion
Beat the confusion, beat the vulnerability.

(1 of 3) Beat the Confusion
• The attack vector is not only MMS
• Trivialized image of attackers should be fixed
• Privileges after the attack is beyond the app
• Even without rooting, practical rooting is possible
from app with no camera/microphone permissions
• Protection by ASLR, claimed by Google,
may not be enough for this time
• Restart doesn’t look anything and precondition of
ASLR safety is virtually unsatisfied
• On some cases, there’s no need to “bypass” ASLR
(just brute force it)

(2 of 3) Make the Future Clear
• Without doubt, this can be the largest
Android security updates!
• Nearly Android specific
• Common in Android
• Wide range of version
• The only practical countermeasure is upgrading
the device so the most recent obstacle is
how do we distribute fixes to users
• In the future, maybe we need to build a system
to reduce upgrade costs and divide responsibility
• Real World Example : Modular Upgrades

(3 of 3) News reports to tell people
• False sense of security is harmful
• We (media and hackers) need cooperation
• To report the vulnerability “correctly”
• Independent research and help will be needed
• Unlike this time, there are some vulnerabilities
that is “told” very serious but actually... seemed not
(e.g. GHOST)
• Providing information with better localization is required
• Let’s make the news report useful for everyone!

END_OF_TRANSMISSION
Thanks for watching!
Special Thanks : Mr. Joshua J. Drake (@jduck)
Presented by : Tsukasa OI (大居司; @a4lg_en)
http://a4lg.com/
Email (feedback) : feedback_2015_stagefright@irq.a4lg.com

The Extras
If you haven’t satisfied and you are an engineer.

インデックス
• Slide 73
• Integer overflow (in case of Java / C#)
• Slide 74-78
• Slide 27 : Vulnerable C++ code and countermeasures
• Slide 79-82
• Exploiting heap overflow and ROP
• Slide 83-85
• SEAndroid and mediaserver
• Slide 86-91
• Japanese news sources and analysis
(sorry, this section is not translated to English)

Integer Overflow (Java / C#)
• Both Java / C# specifies overflown results are
lower bits of two’s complement representation
• C# has “checked” statement to
detect integer overflow
• On the other hand, “unchecked” statement
suppresses integer overflow detection
• Java 8 added integer overflow-detecting
methods to java.lang.Math class
• e.g. addExact / multiplyExact
• Unavailable on Android

Hidden overflow of “new” (1 of 5)
• Array allocation by “new” is not always safe
• ISO/IEC 14882:1998 (C++98) doesn’t specify what would
happen if an integer overflow occurs when
calculating the size of array to be allocated.
• Nearly identical semantics (including integer overflow)
• int* intarray = new(std::nothrow) int[size];
• int* intarray = (int*)malloc(sizeof(int) * size);
• “new” operator should call an allocation function
with size_t-typed argument to allocate an object
• SIZE_MAX is the maximum size of the object
including array.
• For this issue, both compilers and C++
specification added a fix (or two)

• gcc 4.8 and Visual C++ 2005 have compiler-specific
feature to prevent such hidden integer overflow
• If the size has overflown (Visual C++ 2005) or
would overflow (gcc 4.8), they modify the size to allocate
to SIZE_MAX and make allocation function to fail.
• Clang 3.0 or later has similar feature too

• ISO/IEC 14882:2011 (C++11) added
a rule to prevent hidden integer overflow
• Quote from 5.3.4 [New] paragraph 7:
(...) or such that the size of the allocated object would exceed the
implementation-defined limit, (...) no storage is obtained and the new-
expression terminates by throwing an exception of a type that would
match a handler of type std::bad_array_new_length.
• The exception is thrown also by new(std::nothrow)
because this specification is nothing to do with
exceptions thrown/not thrown by allocation functions.
• In C++11, you need to take care of this new type of exception
• That means, the code that had same semantics in C++98
(described before) is no longer “the same” in C++11

• ISO/IEC 14882:2011 (C++11) added
• Note that only gcc 4.9 or later conforms the
C++ specification, strictly
• Android NDK’s gcc 4.9 does not (...somehow)
• Non C++11-compliant compilers do not throw an exception
that would match a handler of type
std::bad_array_new_length
• Instead, allocation function may receive SIZE_MAX
(virtually invalid value)
• Visual C++ 2015 RTM does not conform this specification
• Development version of Clang once conformed this
specification but reverted because of an issue1
1. https://llvm.org/bugs/show_bug.cgi?id=11644

• ISO/IEC 14882:2011 (C++11) added
• “Details” matter
• “would exceed”, not “exceeds”
• “the implementation-defined limit” may not be SIZE_MAX
• gcc 4.8 or later sets about half of the address space
as a limit and performs a comparison in 7-bit precision.
• That means, gcc 4.8 or later may consider overflow even if
the allocation size does not exceed SIZE_MAX or its half.
(This is not obvious behavior but C++11-compliant too)
• I guess this is for some architectures which assigning
immediate value is not fast (including ARM)
• Clang and Visual C++ handles overflow
if allocation size exceeds SIZE_MAX.

Exploiting Heap Overflow (Summary)
• Many possibilities though
• Direct object modification
• Redirect program flow by modifying near objects in the heap
• Overwriting program pointers (such as vtables)
are very close to direct attack (varies)
• Indirect memory modification
• Attack heap allocator itself (depends on the allocator)
• dlmalloc (Android -4.4)
• jemalloc (Android 5.0-)
• Multiple overwrite methods are known to classic dlmalloc
and the attacker can write arbitrary value to arbitrary address
under some circumstances
• My exploit (and Mr. Drake’s one) is based
on direct object modification

Heap Overflow and ROP (1 of 3)
• Comparing to stack overflow
• Stack overflow:
• If we can bypass canary (SSP), it’s very close to direct ROP
• Heap overflow:
• If we cannot overwrite stack, we cannot
redirect to ROP (because of no overwrite to return addresses)
• Overwriting function pointers are classic but just redirecting
random function pointer doesn’t give you a chance for ROP
• So, in many cases, “stack pivot” is used
to overwrite stack pointer (ARM: SP register)
• In demo video shown in Sep 9, I haven’t got a good
stack pivot (due to time constraints) and I used
very dumb method
(Sadly, I was ignorant to stack pivot and heap overflow...)

• In “Android Hacker‘s Handbook” 1, there is
a stack pivot which looks very useful to attackers
• Mr. Drake says it’s work of Mr. Georg Wicherski
• __restore_core_regs (in the dynamic linker)
• Part of libgcc and performs register unwinding
• If we can control R0 (first parameter) and PC
(function pointer), we can overwrite 15 of 16 GPRs:
• R0 to specify buffer for registers
• PC is __restore_core_regs
• Overwriting SP and PC can lead to ROP
• Dynamic linker of Android 4.0 is fixed so ASLR bypass is
pretty easy (for most cases)
1. http://as.wiley.com/WileyCDA/WileyTitle/productCd-111860864X.html (ISBN: 978-1-60864-7)

• However, this pivot is not so generic
• Looking Galaxy Nexus images, this pivot is located on
the linker up to Android 4.2 (not Android 4.3)
• Android 4.1 or later has full ASLR and stack pivot on
the linker is not particularly useful
• We can find alternatives
• ASLR to mmap is based on base address offsetting and
we can find many gadgets under some circumstances
• 9MiB executable and predictable code (~ gadget candidates) on
Android 4.4 attack I used in the demo
• __restore_core_regs can be found in libc
or other many shared libraries

SELinux + mediaserver (1 of 3)
• From Android 4.4 (r1) source code:
external/sepolicy/mediaserver.te
# mediaserver - multimedia daemon
type mediaserver, domain;
permissive mediaserver;
type mediaserver_exec, exec_type, file_type;
net_domain(mediaserver)
init_daemon_domain(mediaserver)
unconfined_domain(mediaserver)
Sets mediaserver domain
as a “permissive” domain
Gives nearly all actions to
mediaserver domain
(set to an unconfined domain)
For permissive domain,
kernel message is printed
if policy violation is found.

• From Android 4.4 (r1) source code:
external/sepolicy/unconfined.te
allow unconfineddomain self:capability_class_set *;
allow unconfineddomain kernel:security ~load_policy;
allow unconfineddomain kernel:system *;
allow unconfineddomain self:memprotect *;
allow unconfineddomain domain:process *;
allow unconfineddomain domain:fd *;
allow unconfineddomain domain:dir r_dir_perms;
allow unconfineddomain domain:lnk_file r_file_perms;
allow unconfineddomain domain:{ fifo_file file } rw_file_perms;
allow unconfineddomain domain:socket_class_set *;
allow unconfineddomain domain:ipc_class_set *;
allow unconfineddomain domain:key *;
allow unconfineddomain fs_type:filesystem *;
allow unconfineddomain {fs_type dev_type file_type}:{ dir blk_file lnk_file sock_file
fifo_file } ~relabelto;
allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file } ~{entrypoint
relabelto};
allow unconfineddomain node_type:node *;
allow unconfineddomain node_type:{ tcp_socket udp_socket rawip_socket } node_bind;
allow unconfineddomain netif_type:netif *;
allow unconfineddomain port_type:socket_class_set name_bind;
allow unconfineddomain port_type:{ tcp_socket dccp_socket } name_connect;
allow unconfineddomain domain:peer recv;
allow unconfineddomain domain:binder { call transfer set_context_mgr };
allow unconfineddomain property_type:property_service set;
For unconfined domains, there are
too many granted “privileges”!
(With no logs eigher!)

• Android 5.0 or later has much better policy
• Not permissive, not unconfined either.
• But as I showed, the attacker can do many
things without avoiding SELinux.

日本における報道 : 分析 (1 of 2)
• この分析に関する情報
• 一連のスライドの記述およびソースの再確認は
9月11日から12日にかけて行った
• 時系列と記事クオリティの “改善”
• 7 月に書かれたものは、すべて “落第”
• 発表の “翻訳” の鵜呑みや、不十分な “対策” の流布
• 8 月以降の記事は技術的に正確な分析なものが
多くなっている
• しかし、MMS の “バランスの悪い” 強調を
十分に止められているとは私は考えていない
• 9 月には私の挙げる 3 条件を満たす記事も少数登場
• 攻撃ルートに関する、
“正確さ” “十分さ (網羅されているか否か)” “バランスの良さ”

日本における報道 : 分析 (2 of 2)
• 初動の悪さ?
• ソーシャルメディアの投稿を大まかに調べると、
多くの人が MMS 無効化を対策として信じる
様子が見受けられる (8 月以降の記事に言及した場合含む)
• ソーシャルメディアの一部において、MMS の無効化が
“対策” になるという空気が醸成されてしまっていた
• 8 月以降の記事 (の一部) の良さを考えると、
初動 (速報) の悪さが尾を引いてしまっている可能性がある
• 改めてソースを分析
• そこまで “悪くない” 報道も多数
• しかし、ソーシャルメディアにおいて醸成された
空気を入れ替えるには至っていない
• 次スライドから良くも悪くも目立った主要ソースを紹介

日本の主要ソース分析 (1 of 4)
• GIGAZINE
• 言及 (2 記事):
• 95％のAndroid端末にMMSを受信するだけで端末を
乗っ取られる脆弱性が発覚、対策はこれ
• 95％ものAndroidがTwitterのリンクをクリック
するだけ・動画再生するだけで乗っ取られる
「Stagefright」攻撃への対応が始まる
• 良いところ
• 情報ソースの選定自体は適切に見える
• 特に後者のソースは攻撃ルートに対する十分かつ正確な言及を含む
• 悪いところ
• 前者における、いわゆる “タイトル釣り”
• しかも、前者には “偽の安心感を生みかねない言及” を含む
• 私にこの資料を書かせたきっかけ (1 of 2)
• 前者の記事についての言及を Twitter で見たのが全ての始まり

• Security Next
• 言及 (1 記事):
• Androidに深刻な脆弱性、MMSで攻撃受けるおそれ
• 良いところ
• 発表に忠実
• 悪いところ
• 発表に忠実
• この速報記事以外を出していない
• 私にこの資料を書かせたきっかけ (2 of 2)
• この言及だけで済ませてしまうことは明らかにマズい
(一般人の保護に十分役立たない)
• この記事以降にフォローアップがあれば良かったが、
情報セキュリティニュースサイトであるにも関わらずそれが無かった

• ASCII.jp + McAfee Blog
• 言及 (1 記事):
• メッセージだけで感染!? 95%のAndroidユーザーに影響する脆弱性
• 良いところ
• MMS 以外の “攻撃” を十分に示せていないものの、
攻撃ルートについては示唆できている
• 悪いところ
• 不十分な “ローカライズ” (翻訳の鵜呑み)
• 日本においては有効に機能しない可能性のある “ヒント” についての言及を含む
• 技術的に十分な対策ができていない製品の宣伝
• McAfee Mobile Security の動作原理上、
当該製品は十分に有効な対策は取れていない (かつ、取れない)

• マイナビニュース
• 言及 (5 記事):
• 「MMSに気をつけろ」って
どういうこと? - いまさら聞けないAndroidのなぜ
• Androidの脆弱性、
応急処置は「MMSメッセージの自動取得無効化」 - Lookout
• 良いところ
• 技術的な分析に関する記述はほぼ正確
• Lookout の記事をソースにするものは
攻撃ルートに関する正確かつ十分な言及を含む
• 悪いところ
• MMS という攻撃ベクトルの “不適切な” 強調
• MMS 以外の攻撃ベクトルに関する記述は MMS に比べて目立たない

Farewell, Stagefright bugs!

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to Farewell, Stagefright bugs!

Similar to Farewell, Stagefright bugs! (20)

More from Tsukasa Oi

More from Tsukasa Oi (9)

Recently uploaded

Recently uploaded (20)

Farewell, Stagefright bugs!