The document discusses the risks associated with native code execution on Android devices, highlighting the vulnerabilities that arise from native code being downloadable and executable at runtime. It proposes a methodology for controlling native code execution to mitigate local privilege escalation attacks and malware, emphasizing the need for security measures to prevent unauthorized privilege escalations. The conclusion presents a flexible and lightweight approach to give users control while ensuring that the vast majority of apps, which do not use native code, remain unaffected.

1. 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

2. Motivation and Teaser
Currently, native code can be downloaded and executed at runtime on
Android devices
Includes (root) exploits
All current root exploits are native code
Allows for adding code after app installation, thus circumventing user
and package manager authority
Should not be possible in our opinion
Any app with Internet access can download and execute root exploits
w/o any hindrance
Our approach: To control local privilege escalation attacks and
malware building upon them, control native code execution
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 1
© Fraunhofer

3. Native Code Execution Control for Attack Mitigation
on Android
Background
Malware on Android
Basic observations: Exploits and native code usage
Native code execution on Android
Approach
Binaries
Libraries
Discussion
Shortcomings
Comparison to other approaches
Conclusion
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 2
© Fraunhofer

4. Malware on Android
Classification
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 install
malicious apps from the net, circumventing the package manager and
permission 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 hazardous
permissions (protection level signatureOrSystem)
Generally, it can do anything and everything; Android’s sandboxing
mechanism no longer applies
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 3
© Fraunhofer

5. Malware on Android
Classification (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

6. Exploits and native code usage
Basic 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, without
affecting most apps at all
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 5
© Fraunhofer

7. Background
Native 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 instruction
pointer 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

8. Background
Native code execution on Android
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 7
© Fraunhofer

9. Background
Advanced 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 app
package 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

10. Native Code Execution Control for Attack Mitigation
on Android
Background
Malware on Android
Basic observations: Exploits and native code usage
Native code execution on Android
Approach
Binaries
Libraries
Discussion
Shortcomings
Comparison to other approaches
Conclusion
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 9
© Fraunhofer

11. Approach
Basic idea
Do not break native code execution, but control what can be executed by
whom
Mandatory or Discretionary (Android permission based) Access Control
solutions possible
Different approaches in the following
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 10
© Fraunhofer

12. Approach
Binaries
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 on
device
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 by
invoking 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

13. Approach
Binaries: 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 mark
binaries as executable → device owners can run root exploits via USB access
Introduce permission for apps to set executable bit & introduce
corresponding 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

14. Approach
Libraries
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

15. Native Code Execution Control for Attack Mitigation
on Android
Background
Malware on Android
Basic observations: Exploits and native code usage
Native code execution on Android
Approach
Binaries
Libraries
Discussion
Shortcomings
Comparison to other approaches
Conclusion
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 14
© Fraunhofer

16. Discussion
Shortcomings
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

17. Discussion
Comparison 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 device
manufacturing altogether
Our approach obviously more flexible
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 16
© Fraunhofer

18. Discussion
Conclusion
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 permission
to 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

19. Contact Information
Rafael Fedler, Marcel Kulicke, and Julian Schütte
Group Mobile Security
Department Service & Application Security
Fraunhofer Research Institution for
Applied and Integrated Security (AISEC)
Address: Parkring 4
85748 Garching (near Munich)
Germany
Internet: http://www.aisec.fraunhofer.de
Phone:
Fax:
E-Mail:
+49 89 3229986-173
+49 89 3229986-299
rafael.fedler@aisec.fraunhofer.de
Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 18
© Fraunhofer