View
10
Download
1
Category
Preview:
Citation preview
Scippa: System-Centric IPC Provenance on Android
Michael Backes, Sven Bugiel, Sebastian Gerling Saarland Univeristy, Germany
1
Presenter: Qi Wang
2014 Annual Computer Security Applications Conference
Android application separation
• One Linux User ID per App
• File system access control via UID
• Permissions bound to App UID
2
Android app components
• Activities – A single screen with a user interface.
• Services – A component that runs in the background to perform long-
running operations.
• Broadcast Receivers – A component that responds to system-wide broadcast
announcements.
• Content Providers – Manage a shared set of app data. Through the content provider,
other apps can query or even modify the data.
3
Inter-app communication on Android
4Wi-Fi
Se,ngsAppSe,ngsWidget “TurnoffWi-Fi”[Bluetooth,GPS,…]
Turnoff
Inter-process communication on Android
5
Wi-Fi
UIComponent
ReceiverComponent
UIDA UIDB
Inter-process communication on Android
6
Wi-Fi
ProcessBoundary
ProcessBoundary
UIComponent
ReceiverComponent
ReceiverComponent
UIDA UIDBUIDS
IPCMechanismmustprovidemessageprovenanceinformaRon.
Binder
• A lightweight IPC mechanism on Android. • The primary channel for inter-app communication.
7
Binder transaction protocol
• Binder IPC provides receiver process with UID/PID of sender process.
8
AppProcessA(Sender) BinderKernelModule
AppProcessS(Receiver)
1. transaction = {recv, payloadA}
2. transaction = {payloadA, UID=A}
If two-way transaction
3. reply = {payloadS}
4. reply = {payloadS}
Losing provenance information
• Cause 1: Message dispatching between threads
9
AppProcessA(Sender)
AppProcessB(Receiver)
IPC Thread Main Thread
BinderKernelModule
calling UID = A
1. trans
2. trans = {P, UID=A}
Dispatch Payload
calling UID =
Losing provenance information
• Cause 2: Indirection communication
10
Intentsender
IntentReceiver
AcRvityMassagerService
A BS
sendintent deliverintent
FirstbindertransacRon
SecondbindertransacRon
Attacks
• Confused deputy attack – A malicious app with an insufficient set of permissions for
its malign purpose tricks a privileged app into executing its privileges on behalf of the malicious app.
• Intent hijacking – A malicious app can intercept an implicit Intent simply by
declaring an Intent filter with all of the actions, data, and categories listed in the Intent.
• Intent spoofing – A malicious app can launch an Intent spoofing attack by
sending an Intent to an exported component that is not expecting Intents from that application.
11
IPC provenance requirements
• Availability of provenance information
• Building system-centric IPC call-chains
• Returning call-chains to senders
• Tagging asynchronous messages – Sticky Broadcast Intents are kept in the system and
are delivered even to recipients that register after the broadcast was sent.
12
Scippa
• System-centric approach to remedy the situation • Extend Binder kernel module and Android’s
message handlers • Build call-chains across multiple app processes • Provide call-chains to all application components • Return call-chains to senders
13
Scippa: idea
14
IPCThread MainThread
callingUID=[A,S]
AppProcessA(Sender) BinderKernelModule SystemProcess
AppProcessB(Receiver)
1stTransacRon
1. transA-S2. transA-SUID=[A]
2ndTransacRon
3. transS-B
4. transS-B={P,UID=[A,S]}DispatchPDispatchUID=[A,S]
Linking nested transactions
15
IPCTransacRonStack:
Trans#1 Trans#1Trans#2 Trans#2
Trans#3 Trans#3
AppA AppB AppC
Trans#1
Trans#2
AppD
Trans#3
UID=[A,B]
UID=[A,B,C]
UID=[A]
ExtendthetransacRondatastructuretoholdcall-chain.
Linking one-way transactions
16
App
IncomingTrans#1
OutgoingTrans#1
OutgoingTrans#2
AppExecuGonState
WaiRngforIPC
ExecuRngincomingtrans#1
ExecuRngincomingtrans#2
Forwardcall-chainfromTrans#2WaiRngforIPC
Storecall-chainfromTrans#1
Forwardcall-chainfromTrans#1
WaiRngforIPCIncomingTrans#2
Storecall-chainfromTrans#2
Further techniques
• Intra-appcall-chainpropagaRon– ExtendedMessage andHandler classesandThread life-cyclefuncRonsofapplicaRonrunRmeenvironment
• TaggingPendingIntentsandsRckyBroadcastIntents– ExtendingIntentclassandBroadcastsubsystem:RestoreIPCcontextfromIntentobjectbeforesending
• Accessingcall-chainsfromuser-space– NewAPIfuncRons:getCallingUids /getCallingPids
• Returningcall-chainstosender– ExtendedBinderprotocolwithBR_CALLCHAIN toreturnfinishedchainbranches
17
Transaction microbenchmark
• Measure 52777 Binder transactions – Weighted average overhead: 2.23%
18
45560
0
1
10
100
1,000
10,000
100,000
0.00%
0.50%
1.00%
1.50%
2.00%
2.50%
32 36 40
Payloa
dFreq
uency
(512BBins)
Performan
ceOverhead
0 4 8 12 16 20 24 28MessagePayload(KB)
Frequency
Overhead
User space benchmark
• Measure the overhead from the app layer perspective
19
3.70-25.33%overhead 12.70-26.73%overhead
Call-chain statistics
20
General Branching Dispatching
#Call-chains:54,670 #Chainswithbranches:54,670(100%)
#Chainswithdispatching:3,237(5.91%)
Chainlength:1.56±0.01
#Branches(total):141,330 #Dispatches(total):24,966
Maxlength:13 #Branches(perchain):2.59±0.08
#Dispatches(perchain):7.71±1.92
IPC provenance evaluation
21
10048:1574:1585
1000:403:698
10048:1574:1574
10045:1679:1690
10044:1658:1677
1000:403:777
10044:1658:1658
10046:1419:1430
10045:1679:1679
10047:1520:1531
10047:1520:1520
1000:403:420
10043:1698:1698
10046:1419:1419 Parallel Broadcast
Ordered Broadcast
Binder IPC
Message Dispatch
IPC Thread
Main Thread Receiver App
System Server Thread
Main Thread Sender App
UID:PID:TID 1000:403:777
Discussion
• What’s the contribution of this paper? • What’s the limitation of Scippa? • Could the feedback mechanism in Scippa violate
privacy? • Call sender&receiver vs. call chain? • What other data can be collected to provide
more sufficient IPC provenance information? • How data provenance could be used in Android
or other areas?
22
Recommended