Tsukasa OIa4lg.com

2015-09-09Japan 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 toreview/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 notapply 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 onand 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 Japanesesuch as “Inside Android Security”

• Pointed out that Android 4.0’s ASLR is not perfect and madepatches 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 bytrusted third-party” by Microsoft Japan in ads 2)

1. https://ja-jp.facebook.com/notes/4559315177579362. 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 PlaybackWhat 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/

The Playback (2 of 5)• 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 unreported1. 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”

The Playback (3 of 5)• 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?)

The Playback (4 of 5)• 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 firstalready 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

The Playback (4 of 5)• 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 BasicsStagefright and the media processing

What is Stagefright anyway?• Stage fright [noun]

→ nervousness felt by a performer orspeaker 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.

What is Stagefright? (2 of 3)• 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 datastructures and parses metadata

• Used in Android• But that wasn’t the end...

What is Stagefright? (3 of 3)• 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!

Media Processing in Android (2 of 3)• 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

Media Processing in Android (3 of 3)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”

6 Buffer Overflow Memory Corruption * Integer overflow

7 Buffer Overflow Crash / Infoleak Integer overflow

8 Buffer Overflow Memory Corruption * Integer overflow

9 Buffer Overflow Crash / Infoleak Invalid handling of strings

10 Buffer Overflow Memory Corruption * Integer overflow

11 Buffer Overflow Memory Corruption * Integer overflow

12 Buffer Overflow Memory Corruption * Integer overflow

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

Integer Overflow and Flaws (2 of 3)• 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 and Flaws (3 of 3)• 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 tograve 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!

ReturnAddress Others

Call history (stack):Subroutine

ASubroutine

B

Overwritten by the attacker!Array (buffer)on the stack

ReturnAddress Others

Call history (stack):

Attacker’s Code

SubroutineB

“Subroutine B” is called by “Subroutine A” butreplaced 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 usefragments of existing code to attack• Example: Classic stack overflow with ROP

(Return-Oriented Programming) to bypass DEP

Overwritten by the attacker!Array (buffer)on the stack

ReturnAddress Attacker’s Code

The attacker cannot run thiscode because of DEP

Overwritten by the attacker!Array (buffer)on the stack

ReturnAddress

ReturnAddress

ReturnAddress

ReturnAddress

ExecutableModule

(in-memory)

Choose useful address inexecutable module in

the memory

Call history (stack):

Gadget4

Gadget3

Gadget2

Gadget1 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 ProofSome may have fun, some may have fear.

Before the Demo...• I cannot perform live demo (sorry!)

• Because I targeted Android 4.4, placing payloaddepends on luck (may take more than an hour)

• So, I prepared videos

• In “The Proof” section, I want you toconfirm attack vectors

• Later, we see what we can do using the payloadplaced 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 attackbut with another vulnerability to bypass ASLR

Demo (2 of 2)• Via: Web browser

• Download executable file and runson 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 / cameraFull 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 andexecute_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 veryspecific 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 isimpossible 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 perspectivethan Zimperium’s demo

The ConfusionConfusions 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 privilegedprocess 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 butvery 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 effectivemitigation 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 messagediscovered; This is the countermeasure – GIGAZINE 1

• What would happen if the reader doesn’t actuallyread 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 1mentioned 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 nothingother 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 only8% 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 foolthe user and let the user trapped• Or, the attacker must work hard to let this attack working

• MMS can be sent without users’ consent andthe attack works when auto-retrieval is enabledso very useful for attackers

• Version 3 of CVSS 1 , Common Vulnerability ScoringSystem includes “User Interaction” to scorevulnerabilities 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 focusedmuch comprehensively• Focusing one too much makes losing other• Should security engineers and medias work together?

The FutureHow 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 byvendor-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 air 1

• Also, they are going to guarantee support lifetime• This is purely great

• Clear support lifetimeIn 3 smartphone OS, all other than Windows Phonehave unclear policy of support lifetime

• Periodic updatesAvoids delay (due to include security update toother kind of update [to save OTA money])

• However, applying this policy to “all” vendorcan 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 bycooperation between Google and other third parties

Binary-Common Userland• Arch Linux ARM on...

• Raspberry Pi 2 Model BSoC : Broadcom

• USB ArmorySoC : 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 butreduce cost to upgrade common parts

Android device

Kernel (Type A)

Common oem.ko Commonuserland

OEMspecific

Some kernels will be neededbecause of hardware differences

Package everything andenable independent upgrades

* This figure is only a hope... But I think this is (partially) possible

Modular Updates (2 of 4)• Example : Windows Phone (7-8)

• Core parts are completely controlled by Microsoftand 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 everything 1

1. http://www.zdnet.com/article/microsoft-says-its-taking-over-updates-for-windows-10-mobile-devices/

Modular Updates (3 of 4)• 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

Modular Updates (4 of 4)• Of course, there are some down sides

• Weak vendor lock-in to hardwareExample : 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 ConclusionBeat 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 possiblefrom 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 upgradingthe device so the most recent obstacle ishow do we distribute fixes to users

• In the future, maybe we need to build a systemto 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 vulnerabilitiesthat 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_TRANSMISSIONThanks 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 ExtrasIf 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 wouldhappen if an integer overflow occurs whencalculating 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 functionwith 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)

Hidden overflow of “new” (2 of 5)• 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 allocateto SIZE_MAX and make allocation function to fail.

• Clang 3.0 or later has similar feature too

Hidden overflow of “new” (3 of 5)• 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 withexceptions 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

Hidden overflow of “new” (4 of 5)• ISO/IEC 14882:2011 (C++11) added

a rule to prevent hidden integer overflow• 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 typestd::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 issue 1

1. https://llvm.org/bugs/show_bug.cgi?id=11644

Hidden overflow of “new” (5 of 5)• ISO/IEC 14882:2011 (C++11) added

a rule to prevent hidden integer overflow• “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 assigningimmediate value is not fast (including ARM)

• Clang and Visual C++ handles overflowif 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 dlmallocand the attacker can write arbitrary value to arbitrary addressunder some circumstances

• My exploit (and Mr. Drake’s one) is basedon 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 usedto 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 usedvery dumb method(Sadly, I was ignorant to stack pivot and heap overflow...)

Heap Overflow and ROP (2 of 3)• 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)

Heap Overflow and ROP (3 of 3)• However, this pivot is not so generic

• Looking Galaxy Nexus images, this pivot is located onthe linker up to Android 4.2 (not Android 4.3)

• Android 4.1 or later has full ASLR and stack pivot onthe 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 daemontype mediaserver, domain;permissive mediaserver;type mediaserver_exec, exec_type, file_type;

net_domain(mediaserver)init_daemon_domain(mediaserver)unconfined_domain(mediaserver)

Sets mediaserver domainas a “permissive” domain

Gives nearly all actions tomediaserver domain

(set to an unconfined domain)

For permissive domain,kernel message is printedif policy violation is found.

SELinux + mediaserver (2 of 3)• From Android 4.4 (r1) source code:

external/sepolicy/unconfined.teallow 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_filefifo_file } ~relabelto;allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file } ~{entrypointrelabelto};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 aretoo many granted “privileges”!

(With no logs eigher!)

SELinux + mediaserver (3 of 3)• 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 で見たのが全ての始まり

日本の主要ソース分析 (2 of 4)• Security Next

• 言及 (1 記事):• Androidに深刻な脆弱性、MMSで攻撃受けるおそれ

• 良いところ• 発表に忠実

• 悪いところ• 発表に忠実• この速報記事以外を出していない

• 私にこの資料を書かせたきっかけ (2 of 2)• この言及だけで済ませてしまうことは明らかにマズい

(一般人の保護に十分役立たない)• この記事以降にフォローアップがあれば良かったが、

情報セキュリティニュースサイトであるにも関わらずそれが無かった

日本の主要ソース分析 (3 of 4)• ASCII.jp + McAfee Blog

• 言及 (1 記事):• メッセージだけで感染!? 95%のAndroidユーザーに影響する脆弱性

• 良いところ• MMS 以外の “攻撃” を十分に示せていないものの、

攻撃ルートについては示唆できている• 悪いところ

• 不十分な “ローカライズ” (翻訳の鵜呑み)• 日本においては有効に機能しない可能性のある “ヒント” についての言及を含む

• 技術的に十分な対策ができていない製品の宣伝• McAfee Mobile Security の動作原理上、

当該製品は十分に有効な対策は取れていない (かつ、取れない)

日本の主要ソース分析 (4 of 4)• マイナビニュース

• 言及 (5 記事):• 「MMSに気をつけろ」って

どういうこと? - いまさら聞けないAndroidのなぜ• Androidの脆弱性、

応急処置は「MMSメッセージの自動取得無効化」 - Lookout• 良いところ

• 技術的な分析に関する記述はほぼ正確• Lookout の記事をソースにするものは

攻撃ルートに関する正確かつ十分な言及を含む• 悪いところ

• MMS という攻撃ベクトルの “不適切な” 強調• MMS 以外の攻撃ベクトルに関する記述は MMS に比べて目立たない