PREC: Practical Root Containment For Android Devices

Recently, I had come across this paper which was published by professors from NCSU.  Google Play is the new hub of distributing Malwares to the Android devices. A recent survey said that around 70% of the apps in the Google play are malwares. Currently, there’s no robust and 100% accurate mechanism in Google play to detect the presence of Malicious code in the app which a user submits.  PREC can dynamically identify system calls from high-risk components (e.g., third- party native libraries) and execute those system calls within isolated threads. Hence, PREC can detect and stop root exploits with high accuracy while imposing low interference to benign applications.

My understanding

Existing problems

  1. Failure of Google play for detecting malicious applications
  2. Current apps are intelligent enough to detect the emulated environment (Google play test on emulated env)
  3. Environment couldn’t differentiate apps uses third party native codes which may be malicious (not all time)

Contributions of the paper

  1. An architecture for mitigating root exploit malware that hides its existence during dynamic analysis. The approach mentioned in the proposal forces malware to commit to a normal behavior during dynamic analysis (Google play) and malicious attacks are detected and stopped at run time (on device)
  2. A run time, kernel level, system call origin identification mechanism that is used to build a fine grained behavior models for higher anomaly detection accuracy and practical malware containment
  3. Introduced a scalable and robust behavior learning and anomaly detection scheme using self organizing map (SOM) learning algorithm that can achieve both high accuracy and low overhead

During dynamic analysis, PREC records and labels each system call as originating either from third party native code or from Java code.
Current scenario:

  1. All existing malware that exploits root privilege escalation vulnerability uses third party native code
  2. Low level system APIs required by root exploits are not often available to Java code
  3. Program analysis of third party native code is significantly more difficult than Java code or system libraries, hence most malware analysis tools ignore such third party native codes

Design and Implementation details

System call identification

Approach 1: Perform classified system call monitoring by separating the system call originating from high risk third party from the system calls issued by low dangerous Java code.
Cons of approach 1: Java and third party native code uses system provided native libraries to invoke system call. Hence need to differentiate between both.
Approach 2: Dalvik VM notifies Kernel when a thread switches to third party code. The kernel can maintain a flag afterwards.
Cons of Approach 2: Vulnerable to a confused deputy attack:- the kernel cannot determine if the flag change request was from Dalvik VM or third party native code.
Approach 3:A thread based approach: Maintains a pool of special threads called native threads and execute all the third party native functions using these native threads. Malicious code cannot change a native thread to a normal thread. No communication is required between Dalvik VM and Kernel since pool of native thread are created bu PREC at app launch time.
When a Java thread needs to execute a third party native function, the Java thread is suspended and an idle native thread is dynamically selected to execute native function. This native thread is killed only after the native function ends its execution.
Pros:

  1. Kernel tracer can easily identify the system call origins (from Java or native components
  2. The thread based approach isolates only small portion of the application => no need to kill the whole application
  3. PREC can easily incoporate other executions sandboxing mechanims to provide additional security isolation between Java and malicious native code.

Main challenges authors faced

  1. Making run time root exploit containment practically achievable at a low false alarm rate
  2. Imposing low interference to benign applications
Advertisements

One comment

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