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