On the Effectiveness of API-Level Access Control Using Bytecode Rewriting in Android
Presenter: Lu Gong
2
Authors
• Students: Hao Hao, Vicky Singh• Professor: Wenliang (Kevin) Du
• Dept. of EE & CS, Syracuse University, New York
3
The Conference
• AsiaCCS:– ACM Symposium on Information, Computer
and Communications Security• Rank C in the CCF recommendation list
– Network and Information Security
4
The paper
• The first systematic study on the effectiveness of using bytecode rewriting for API-level access control
• Cited by:– Structural detection of android malware using
embedded call graphs (AISec ’13)– Compac: Enforce Component-Level Access
Control in Android (ACM CodaSpy ’14)
5
Background (1/3)
• Bytecode rewriting– Use static analysis to identify sensitive API
calls– Instrument bytecode to control access– Aim at implement fine-grained access control
6
Background (2/3)
• API-Level Access Control
7
Background (3/3)
• Method invocation instructions:– invoke-virtual: used to invoke a normal virtual method– invoke-direct: used to invoke either a private instance
method or a constructor– invoke-static: used to invoke a static method– invoke-interface: used to invoke an interface method
on an object whose concrete class is not known– invoke-super: used to invoke the closest superclass’
virtual method
8
Scoping (1/5)
• Two kinds of byte-code rewrite mechanisms:1. Put the reference monitor in another service2. Put the reference monitor within the application
• Only focus on the second approach– Because the first one is fail-safe
9
Scoping (2/5)
• Assumption– The application either do not have native code
or their native code is blocked from being executed
• Reasons– Native code is running in the same process
space as DVM– With native code, the app can easily tamper the
DVM state, thus byte-code rewriting is useless
10
Scoping (3/5)
• Privileged resources– Hardware devices– Kernel data– Data from another process space
• Ways to access them– System calls– Inter-process communication
11
Scoping (4/5)
12
Scoping (5/5)
• Concealing API usage (the 4th attack) is possible– Java reflection
– Dynamic binding
13
Prelude (1/2)
• Byte-code rewriting for a non-final class
14
Prelude (2/2)
• Byte-code rewriting for a final class
15
Methodology
1. Study all possible attacks against bytecode rewriting
2. Give deeper insight into the attacks3. Make recommendations on how to
defend against these attacks
16
Exploit JNI Naming Convention
17
The JNI naming convention
18
Dynamic binding
19
The problem
Java_MyClass_my_1Func
MyClass.my.1Func()
MyClass.my_Func()
20
Case study
21
Recommendations
• If any names starts with numbers, bytecode rewriter should remove the digit as it is illegal.
22
Exploit Java Class Reloading
23
Example
24
Case Study (1/2)
25
Case Study (2/2)
26
27
Recommendations
• Stop application’s Java code from reloading preloaded Android core classes– BaseDexClassLoader.findClass()– DexFile.loadClass()
28
Exploit Customized RPC stubs
29
Case Study (1/2)
30
Case Study (2/2)
31
32
Recommendation
• Apply API-level access control on android.os.ServiceManager.getService()
• Alternative: rewrite android.os.Binder
33
Conclusion
• Although all problems are fixable, more static analysis and dynamic checking should be performed while byte-code rewriting
Thank you