Scippa: System-Centric IPC Provenance on Android Michael Backes, Sven Bugiel, Sebastian Gerling Saarland Univeristy, Germany 2014 Annual Computer Security Applications Conference Presenter: Qi Wang 1
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 Se,ngs Widget “Turn off Wi-Fi” [Bluetooth, GPS,…] Se,ngs App Turn off Wi-Fi 4
Inter-process communication on Android UID A UID B UI Receiver Component Component Wi-Fi 5
Inter-process communication on Android Process Process UID A Boundary UID S Boundary UID B UI Receiver Receiver Component Component Component IPC Mechanism must provide message Wi-Fi provenance informaRon. 6
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. App Process A App Process S (Sender) Binder Kernel Module (Receiver) 1. transaction = {recv, payload A } 2. transaction = {payload A , UID=A } If two-way transaction 3. reply = {payload S } 4. reply = {payload S } 8
Losing provenance information • Cause 1: Message dispatching between threads App Process A App Process B (Sender) Binder Kernel Module (Receiver) IPC Thread Main Thread 1. trans 2. trans = {P , UID=A } Dispatch Payload calling UID = calling UID = A 9
Losing provenance information • Cause 2: Indirection communication A S B AcRvity deliver intent send intent Intent Intent Massager sender Receiver Service First binder Second binder transacRon transacRon 10
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 App Process A App Process B (Sender) Binder Kernel Module System Process (Receiver) IPC Thread Main Thread 1 st TransacRon 1. trans A-S 2. trans A-S UID=[A] 2 nd TransacRon 3. trans S-B 4. trans S-B = {P, UID=[A,S] } Dispatch P Dispatch UID=[A,S] calling UID = [A,S] 14
Linking nested transactions App A App B App C App D Trans #1 UID=[A] Trans #2 UID=[A,B] Trans #3 UID=[A,B,C] IPC TransacRon Stack: Trans #3 Trans #3 Trans #2 Trans #2 Trans #1 Trans #1 Extend the transacRon data structure to hold call-chain. 15
Linking one-way transactions App App ExecuGon State WaiRng for IPC Incoming Trans #1 Store call-chain from Trans #1 ExecuRng incoming trans #1 Outgoing Trans #1 Forward call-chain from Trans #1 WaiRng for IPC Incoming Trans #2 Store call-chain from Trans #2 ExecuRng incoming trans #2 Outgoing Trans #2 Forward call-chain from Trans #2 WaiRng for IPC 16
Further techniques • Intra-app call-chain propagaRon – Extended Message and Handler classes and Thread life-cycle funcRons of applicaRon runRme environment • Tagging Pending Intents and sRcky Broadcast Intents – Extending Intent class and Broadcast subsystem: Restore IPC context from Intent object before sending • Accessing call-chains from user-space – New API funcRons: getCallingUids / getCallingPids • Returning call-chains to sender – Extended Binder protocol with BR_CALLCHAIN to return finished chain branches 17
Transaction microbenchmark • Measure 52777 Binder transactions – Weighted average overhead: 2.23% 2.50% 100,000 45560 Frequency 10,000 2.00% Performance Overhead Payload Frequency Overhead 1,000 (512 B Bins) 1.50% 100 1.00% 10 0.50% 1 0.00% 0 0 4 8 12 16 20 24 28 32 36 40 Message Payload (KB) 18
User space benchmark • Measure the overhead from the app layer perspective 3.70-25.33% overhead 12.70-26.73% overhead 19
Call-chain statistics General Branching Dispatching #Call-chains: 54,670 #Chains with branches: 54,670 #Chains with dispatching: (100%) 3,237 (5.91 %) Chain length: #Branches (total): 141,330 #Dispatches (total): 24,966 1.56±0.01 Max length: 13 #Branches (per chain): #Dispatches (per chain): 2.59±0.08 7.71±1.92 20
IPC provenance evaluation Binder IPC 10046:1419:1419 Parallel Broadcast Message Dispatch IPC Thread 10048:1574:1574 Main Thread Receiver App System Server Thread Main Thread Sender App 10046:1419:1430 10047:1520:1520 UID:PID:TID 1000:403:777 Ordered Broadcast 10044:1658:1658 10048:1574:1585 10044:1658:1677 10047:1520:1531 1000:403:420 1000:403:698 10045:1679:1679 10043:1698:1698 1000:403:777 10045:1679:1690 21
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
Recommend
More recommend
