19
Native Code Execution Control for Attack Mitigation on Android 3rd Annual ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM) Rafael Fedler, Marcel Kulicke, and Julian Schütte, November 8, 2013

Native Code Execution Control for Attack Mitigation on Android

Embed Size (px)

DESCRIPTION

In this talk, researchers from Fraunhofer AISEC demonstrate how Android can be made immune against all current local root exploits. The techniques detailed in this talk significantly raise the hurdles for successful potent attacks on Android devices and strongly limit the capabilities of malware. Currently, any app with Internet access can download code via the network at runtime and execute it, without the user or the system noticing. This includes malicious code such as root exploits. These flaws are addressed by the paper presented in this talk, entitled "Native Code Execution Control for Attack Mitigation on Android". The presentation was given at the 3rd Annual Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM'13), colocated with the ACM Conference on Computer and Communications Security 2013 (CCS'13) in Berlin, Germany. If you are interested in our techreport "On the Effectiveness of Malware Protection on Android" please visit http://ais.ec/techreport

Citation preview

Page 1: Native Code Execution Control for Attack Mitigation on Android

Native Code Execution Control for Attack Mitigationon Android

3rd Annual ACM CCS Workshop on Security and Privacy in Smartphones andMobile Devices (SPSM)Rafael Fedler, Marcel Kulicke, and Julian Schütte, November 8, 2013

Page 2: Native Code Execution Control for Attack Mitigation on Android

Motivation and Teaser

� Currently, native code can be downloaded and executed at runtime onAndroid devices

� Includes (root) exploits� All current root exploits are native code

� Allows for adding code after app installation, thus circumventing userand package manager authority

� Should not be possible in our opinion

� Any app with Internet access can download and execute root exploitsw/o any hindrance

Our approach: To control local privilege escalation attacks andmalware building upon them, control native code execution

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 1

© Fraunhofer

Page 3: Native Code Execution Control for Attack Mitigation on Android

Native Code Execution Control for Attack Mitigationon AndroidBackground

Malware on AndroidBasic observations: Exploits and native code usageNative code execution on Android

ApproachBinariesLibraries

DiscussionShortcomingsComparison to other approachesConclusion

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 2

© Fraunhofer

Page 4: Native Code Execution Control for Attack Mitigation on Android

Malware on AndroidClassification

Trivial classification:

1. Malware using root exploits

2. Malware not using root exploits

For obvious reasons, 1. much more dangerous:

� Droppers or disguised, seemingly legitimate apps can silently installmalicious apps from the net, circumventing the package manager andpermission system

� If no NAND write protection: Irremovable installation of malicious apps to/system partition (usually mounted read-only)

� Apps installed on /system get access to potentially hazardouspermissions (protection level signatureOrSystem)

� Generally, it can do anything and everything; Android’s sandboxingmechanism no longer applies

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 3

© Fraunhofer

Page 5: Native Code Execution Control for Attack Mitigation on Android

Malware on AndroidClassification (2) & Further problems

Class 2, on the other hand...

� Has to trick the user into manually installing malware

� Far more limited control over device

� Can be uninstalled by user

Trivial conclusion: Root exploits problematic – Cpt. Obvious

Additional problems:� Device vendors’ patch policy

� Patches take many months, if supplied at all� End of life for products often < 1.5 years� Consequence: Many devices vulnerable to exploits for very long time

� Antivirus software extremely easy to fool� Root exploits downloaded at runtime completely invisible to AV

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 4

© Fraunhofer

Page 6: Native Code Execution Control for Attack Mitigation on Android

Exploits and native code usageBasic observations

1. All current root exploits exclusively implemented as native code� Reasons:

� C header files → ease of development� System call interfaces for privilege escalation� Some creative tricks, e.g., excessive spawning of processes to hit

RLIMIT_NPROC (RageAgainstTheCage)� Flexibility for memory manipulation and system interaction

� Currently only as standalone binaries, no libraries

2. Less than 5% of all apps in Google Play Store use native code at all� Mostly libraries, almost no binaries

Our conclusion: Control native code to control exploits, withoutaffecting most apps at all

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 5

© Fraunhofer

Page 7: Native Code Execution Control for Attack Mitigation on Android

BackgroundNative code execution on Android

Two (official) ways:

1. Binaries� Process, ProcessBuilder, Runtime API classes from within apps� Need to be marked executable beforehand (!)

2. Libraries� System API class: load() and loadLibrary() from within apps� No need to mark executable before executing

3. Inofficial: Load/map machine code into memory space, make instructionpointer point to beginning of code

� Only works from within native code, not from within apps in Dalvik

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 6

© Fraunhofer

Page 8: Native Code Execution Control for Attack Mitigation on Android

BackgroundNative code execution on Android

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 7

© Fraunhofer

Page 9: Native Code Execution Control for Attack Mitigation on Android

BackgroundAdvanced malware: Typical chain of actions until infection

1. Initial propagation� Disguised as a legitimate app� Repackaged� Update of legitimate app after hijacking of developer’s account and

signing key� etc.

2. Download of root exploit at runtime, in case it is not shipped with apppackage file

3. Mark exploit executable with chmod

4. Execute root exploit and carry out payload

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 8

© Fraunhofer

Page 10: Native Code Execution Control for Attack Mitigation on Android

Native Code Execution Control for Attack Mitigationon AndroidBackground

Malware on AndroidBasic observations: Exploits and native code usageNative code execution on Android

ApproachBinariesLibraries

DiscussionShortcomingsComparison to other approachesConclusion

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 9

© Fraunhofer

Page 11: Native Code Execution Control for Attack Mitigation on Android

ApproachBasic idea

� Do not break native code execution, but control what can be executed bywhom

� Mandatory or Discretionary (Android permission based) Access Controlsolutions possible

� Different approaches in the following

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 10

© Fraunhofer

Page 12: Native Code Execution Control for Attack Mitigation on Android

ApproachBinaries

� Control ability to set the executable bit� No scenario where an app should mark anything executable at runtime

� Undermines the system’s & user’s authority over runnable software ondevice

� Apps should ship all software at install time and not be able to download& execute code from the net at runtime

� −→ default case: disallow setting the executable bit for files

� Exception: directories (different semantics of executable bit)� Checks to be integrated into (f)chmod system call interface in kernel

� Could be circumvented if integrated into chmod utility or libc stub byinvoking syscall

� No problem for preshipped binaries: file system image manipulation

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 11

© Fraunhofer

Page 13: Native Code Execution Control for Attack Mitigation on Android

ApproachBinaries: Potential exceptions

� Problem with last slide’s MAC approach: Device owners want to root, too� Potential MAC or DAC remedies:

1. UID or GID based exceptions� Introduce option into AndroidManifest.xml and let package manager mark

specified binaries executable + according permission(would still prevent download & execution at runtime)

� Whitelist root (UID 0) and shell (UID 2000) user s.t. they can still markbinaries as executable → device owners can run root exploits via USB access

� Introduce permission for apps to set executable bit & introducecorresponding GID

2. Permission-based exceptions� Introduce permissions into Process, ProcessBuilder and Runtime

classes’ methods for executing binaries� If dangerous protection level: DAC� If signature or signatureOrSystem protection level: MAC

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 12

© Fraunhofer

Page 14: Native Code Execution Control for Attack Mitigation on Android

ApproachLibraries

� Controlling binaries alone would trigger a shift to native libraries� Three approaches:

1. Loader- and filesystem-based� Require executable bit also for libraries & make System.load() and

System.loadLibrary() check for it� Thus, the aforementioned measures for binaries would apply to libraries too

2. Permission-based� Secure the System class with a permission� To be granted by users at installation time� Retains possibility to still play games

3. Path-based� Restrict System.load() and System.loadLibrary() to default

path for preinstalled libraries� Allows developers to still use preshipped libraries, but no own native code

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 13

© Fraunhofer

Page 15: Native Code Execution Control for Attack Mitigation on Android

Native Code Execution Control for Attack Mitigationon AndroidBackground

Malware on AndroidBasic observations: Exploits and native code usageNative code execution on Android

ApproachBinariesLibraries

DiscussionShortcomingsComparison to other approachesConclusion

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 14

© Fraunhofer

Page 16: Native Code Execution Control for Attack Mitigation on Android

DiscussionShortcomings

� mmap() some code + just jump into it� mmap() can only be called from within native code→ initial protection

still provided� Tampering with mmap() at kernel level can break library loading

mechanisms and much more

� Return-oriented programming inside preshipped libraries/binaries

� Exploits targeting Dalvik not covered

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 15

© Fraunhofer

Page 17: Native Code Execution Control for Attack Mitigation on Android

DiscussionComparison to other approaches

� SEAndroid: achieves the same (and even more)� Requires extensive policies, not very lightweight, needs configuration

� Removing executability of any native code added after devicemanufacturing altogether

� Our approach obviously more flexible

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 16

© Fraunhofer

Page 18: Native Code Execution Control for Attack Mitigation on Android

DiscussionConclusion

� Different levels of strictness and protection possible (MAC or DAC)� Not perfect, but...

� lightweight compared to MAC approaches s.a. SEAndroid� no policies required� flexible

� Users may (DAC: permission-based) or may not (MAC) grant apps permissionto still run native code

� Openness to modification retained

� All current root exploits would fail

� Hurdles of exploitation strongly increased

� 95% of apps not affected at all as they do not run native code

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 17

© Fraunhofer

Page 19: Native Code Execution Control for Attack Mitigation on Android

Contact Information

Rafael Fedler, Marcel Kulicke, and Julian Schütte

Group Mobile SecurityDepartment Service & Application Security

Fraunhofer Research Institution forApplied and Integrated Security (AISEC)

Address: Parkring 485748 Garching (near Munich)Germany

Internet: http://www.aisec.fraunhofer.de

Phone: +49 89 3229986-173Fax: +49 89 3229986-299E-Mail: [email protected]

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 18

© Fraunhofer