Paper reading 1

I will post some of the research papers which I have read as a part of the literature survey for my master’s degree thesis:

Security Analysis of Android Factory Resets (AFR)[1]

Introduction

  • Raises doubts against the current security of the factory settings of Android devices
  • Improper sanitization of the data partition leads to exposure/recovery of user credentials due to flawed factory reset

Problem definition

  • The amount of data left behind by flawed implementations
  • The drivers being flawed
  • Critical failures of AFR pointed out by the researchers
    • The lack of Android support for proper deletion of data partition
    • Incompleteness of upgrades pushed to flaws by vendors
    • The lack of driver support for proper deletion shipped by vendors in new devices
    • The lack of Android support in the deletion of internal and external SD card in all SDKs
    • The fragility of full-disk encryption to mitigate problem upto Android v4.4

Contribution of the research paper

  • The first comprehensive study of AFR, by analyzing the security of 21 devices from 5 different vendors running Android v2.3x – v4.3
  • Discovered critical failures of the Android OS and/or vendor shipped devices for the secure deletion of user data and account details during AFR .
  • Suggestion for improving for Google and vendors to mitigate the future risks

Mentioned about three ioctl() functions MEMERASE, BLKDISCARD, BLKSECDISCARD,  used for sanitising the data partitions.

Results

  1. The sanitisation of the external storage occurs only if a user selects the additional option “External Storage” or “Secondary Storage” in the AFR
  2. Data partitions store the confidential data about Google and third party apps. It was found that devices which were upgraded from v2.3 to v4.0 doesn’t update the device driver for ioctl to execute BLKSECDISCARD on the logical sanitising functionality from the underlying eMMC.
  3. The phones released with newer version of Android ICS and JB seems to have the same issues as the mobile phone vendor hasn’t provided the updated device drivers of ioctl() to call secure logical sanitization functions.

Suggestions to improve

  1. An app to overwrite the entire partition “bit-by-bit”. But it requires root permission
  2. AOSP supports full disk encryption but it is uses user (4-6 digit) PIN to encrypt the entire data/external partition.

Open research questions

  1. Investigate security of digital sanitisation of very recent devices (models above Android v4.4) after an AFR

ROP is still Dangerous: Breaking Modern Defences[2]

Problem statement:
Failures of existing ROP defense mechanism

Novelty:

  1. Introduces three novel techniques to bypass the existing defense mechanism of ROP attacks.
  2. A baseline set of attacks that can be used to evaluate future ROP defenses
  3. Bypasses the state-of-art ROP defenses including kBouncer and ROPecker

Existing ROP defense techniques:

  1. Call preceded ROP: Normally, every ret instruction returns back to an instruction that immediately follows a corresponding call. ROP attacks deviate from this pattern.
  2. Evasion attacks: Anomaly detection at runtime. ROP attacks tries to make it appear as normal. ROP defenses check if there’s any short gadgets. Discards long gadgets. An attacker can evade this protection by using long gadgets.
  3. History Flushing: Defense inspect limited memory execution history and inspect them for any possible ROP attacks. This could be evaded by overwriting with a fake history

kBouncer

Overview

  1. Inspects last 16 indirect branches taken each time the program invokes a system call
  2. It verifies that all ret instructions in the LBR returned to a call-preceded address.
  3. If the eight most recent indirect branches are all gadget like, the process is killed

Attack overview

  1. Initial exploitation: A traditional ROP payload is mounted in the easiest way discarding the fact that kBouncer is present in the system. Memory is prepared to make syscalls but not yet ready to invoke
  2. Hide the history: Before invoking a system call, history hiding attack is launched. As a side effect, the registered may be clobbered but memory locations remains unchanged. A termination gadget is used to terminate kBouncer’s backward search for gadget like sequences.
  3. Restore the registers and issue system call: After bringing the process into a valid state, the registered are restored into their desired values. Then system call is issued via evasion attack. It is achieved using less than 8 call-preceded gadgets

Requirements for future defenses against ROP

  1. Either the defenses should have access to all the previous history or with the limited history should not be cleared out by the attacker.
  2. Defenses that defend against one specific aspect of ROP must argue that is a necessary component of one

Open research problem

  1. A general purpose defense against ROP attacks
  2. Find the fundamental difference between the ROP attacks and typical program execution

Android Prespective

kBouncer and ROPecker is not yet implemented for Android. Hence Android kernels are vulnerable to ROP attacks.

Dune: Safe User-Level Access to Privileged CPU features[3]

Dune provides applications with direct but safe access to hardware features such as ring protection, page tables and tagged TLB. Dune uses the virtualization hardware in modern processors to provide a process than a machine abstraction. It includes a small kernel module that instantiates virtualization hardware and mediates interactions with kernel and a user level library that helps applications manage privileged hardware features. Applications of Dune: sandboxing, privilege separation, and garbage collection.

Contributions

  1. A design that uses hardware-assisted virtualization to safely and efficiently expose privileged hardware features to user programs while preserving standard OS abstractions.
  2. Evaluates three hardware features in detail and show how they can benefit user programs: exceptions, paging, and privilege modes.
  3. Demonstration of the end-to-end utility of Dune by implementing and evaluating three use cases: sandboxing, privilege separation, and garbage collection

Open research topics

  1. Currently supports x86 CPUs and Intel VT-x. Could be extended to ARM x86 and x64. Requires to create an efficient architecture independent interface of libDune.
  2. Utilities in libDune are not thread safe. Support of libc Signal calls (signal, sigaction)
  3. Android sandboxing could be achieved by implementing Dune (VMX ring3, non root mode) on top of the underlying Linux kernel. ART could run on top of Dune.

References:

[1] http://www.cl.cam.ac.uk/~rja14/Papers/fr_most15.pdf

[2] http://nicholas.carlini.com/papers/2014_usenix_ropattacks.pdf

[3] http://www.scs.stanford.edu/~dm/home/papers/belay:dune.pdf

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s