Native Code Execution Control for Attack Mitigation
on Android
3rd Annual ACM CCS Workshop on Security and Privacy in Smar...
Motivation and Teaser
Currently, native code can be downloaded and executed at runtime on
Android devices
Includes (root) ...
Native Code Execution Control for Attack Mitigation
on Android
Background
Malware on Android
Basic observations: Exploits ...
Malware on Android
Classification
Trivial classification:
1. Malware using root exploits
2. Malware not using root exploits
...
Malware on Android
Classification (2) & Further problems
Class 2, on the other hand...
Has to trick the user into manually ...
Exploits and native code usage
Basic observations
1. All current root exploits exclusively implemented as native code
Reas...
Background
Native code execution on Android

Two (official) ways:
1. Binaries
Process, ProcessBuilder, Runtime API classes ...
Background
Native code execution on Android

Native Code Execution Control for Attack Mitigation on Android | Rafael Fedle...
Background
Advanced malware: Typical chain of actions until infection

1. Initial propagation
Disguised as a legitimate ap...
Native Code Execution Control for Attack Mitigation
on Android
Background
Malware on Android
Basic observations: Exploits ...
Approach
Basic idea

Do not break native code execution, but control what can be executed by
whom
Mandatory or Discretiona...
Approach
Binaries
Control ability to set the executable bit
No scenario where an app should mark anything executable at ru...
Approach
Binaries: Potential exceptions
Problem with last slide’s MAC approach: Device owners want to root, too
Potential ...
Approach
Libraries
Controlling binaries alone would trigger a shift to native libraries
Three approaches:
1. Loader- and fi...
Native Code Execution Control for Attack Mitigation
on Android
Background
Malware on Android
Basic observations: Exploits ...
Discussion
Shortcomings

mmap() some code + just jump into it
mmap() can only be called from within native code → initial ...
Discussion
Comparison to other approaches

SEAndroid: achieves the same (and even more)
Requires extensive policies, not v...
Discussion
Conclusion

Different levels of strictness and protection possible (MAC or DAC)
Not perfect, but...
lightweight...
Contact Information
Rafael Fedler, Marcel Kulicke, and Julian Schütte
Group Mobile Security
Department Service & Applicati...
Upcoming SlideShare
Loading in...5
×

Native Code Execution Control for Attack Mitigation on Android

739

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
739
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Native Code Execution Control for Attack Mitigation on Android

  1. 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. 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. 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. 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. 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. 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. 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. 8. Background Native code execution on Android Native Code Execution Control for Attack Mitigation on Android | Rafael Fedler | November 8, 2013 | 7 © Fraunhofer
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×