Transcript Paranoid Android: Versatile Protection For Smartphones

Georgios Portokalidis
Philip Homeburg
Kostas Anagnostakis
Herbert Bos
Columbia University
Vrije Universiteit
Niometris R&D
Vrije Universiteit
PARANOID ANDROID:
VERSATILE PROTECTION FOR
SMARTPHONES
2010/11/30
1
Paranoid Android?
Click this album
to play this
song …
2010/11/30
2
Outline
 Introduction
 Architecture
 Implementation
 Evaluation
 Related Work
 Conclusion
2010/11/30
3
Introduction
 Recently, iPhone and Android platform have
shown to be susceptible to remote exploits
 Obama’s blackberry
2010/11/30
4
Introduction
 Using a file scanner or antivirus, like ClamAV
 Time-consuming (30 minutes)
 Battery problem (2% battery capacity)
 Is 11.8x slower than running it on single-core VM
 We argue for a different security model that
completely devolves attack detection from the
phone
 Key: Cloud !
2010/11/30
5
Introduction
 Antivirus file scanning
 Zero-days? Remote exploits? Memory-resident
attacks?
 Smartphone APIs
 Android: Java Dalvik VM
 But also provide native APIs
 May be vulnerable to these attacks
2010/11/30
6
Introduction
 Contributions:
 Multiple security checks simultaneously without




overburdening the device
Execution recording and replaying framework for
Android
Transparent backup of all user data in the cloud
Replication mechanism
Application transparent recording and replaying
2010/11/30
7
Architecture
 Tracer
 Record all info needed to accurately replay its
execution
 Replayer
 Receive the trace and faithfully replays the
execution within the emulator
 Proxy
 Intercept and temporarily store inbound traffic
 The replayer can access the proxy to retrieve the
data needed for replaying
2010/11/30
8
Architecture
2010/11/30
9
Architecture
 Assumptions
 The replay server will not be compromised
 Attackers cannot break the encryption
 The device is able to contact the server safely, to
create an initial replica, and setup the tracer
 The servers have out-of-band channels to notify
users about problems and a way to restore the
image
2010/11/30
10
Architecture
 Tracer
 Nondeterministic inputs and events
 Mostly pass through the system calls
 Record all data transferred from kernel to user
space through system calls
2010/11/30
11
Architecture
 Replayer
 Use the recorded values when replaying the
system calls on replica
 Including IPC using system calls
 Only replay process and not kernel execution
 May not be able to detect an attack against the
kernel
 But most kernel vulnerabilities are only exploitable
locally
 Shared memory: repeatable deterministic task
scheduler
2010/11/30
12
Architecture
 Synchronisation
 Loose Synchronisation
 Transmit the trace only when the device is awake
and connected to the Internet
 User is most likely to be attacked while surfing the web
 Support extremely sychronisation
 Only sync when recharging
2010/11/30
13
Architecture
 Synchronisation
 Tamper-Evident Secure Storage
 HMAC: Hash-based Message Authentication Code
 HMAC = Hash( K xor opad, Hash(K xor ipad, text))
 STORE(message + HMAC(key, message))
 key’ = Hash(key)
 key = key’
 If sync error, the device is treated as
potentially compromised
2010/11/30
14
Architecture
 Security Methods
 Dynamic analysis in emulator
 Antivirus software
 Memory scan
 System call detection
 P.S. only implement the first two
2010/11/30
15
Architecture
 Proxy and Server Location
 User Notification and Recovery
 Handling Data Generated On the Device
 Bulk downloads
 Incremental downloads
2010/11/30
16
Implementation
 Need a new boot image!
 Linux ptrace
 PTRACE_SYSCALL
2010/11/30
17
Implementation
 Starting The Tracer
 Init starts tracer first
 Next, init starts the exec stubs
 The stub writes its pid to tracer’s FIFO and pauses
 Then tracer attaches to the process, and
continues the stub
 Exec
2010/11/30
18
Implementation
 Scheduling And Shared Memory
 User space Scheduler
 Ensuring no two threads that share a memory
object can ever run concurrently
 Triggered by system call
 Spinlock and mutexes
 Future work
 CREW protocol (concurrent-read-exclusive-write)
 To track all reads from memory
2010/11/30
19
Implementation
 Ioctls
 An interface between user and kernel space
 /dev/binder
 Handles about 200 ioctl commands
2010/11/30
20
Implementation
 Execution Trace Compression
 Record only system calls that introduce
nondeterminism
 Use a network proxy so that inbound data are not
logged in the trace
 Compress data using three algorithms
 Delta encoding
 Huffman encoding
 DEFLATE algorithm (gzip)
2010/11/30
21
Implementation
 Attack Detection Mechanisms
 Virus Scanner
 ClamAV
 Dynamic Taint Analysis
 Overhead imposed is high
 Only on replica
2010/11/30
22
Evaluation
 HTC G1 with tracer
 Modified QEMU for replayer
2010/11/30
23
Evaluation
2010/11/30
24
Evaluation
 Data Volume:
 5 hours of audio
playback
 22.5 MB
64B/s
121B/s
2010/11/30
25
Evaluation
 CPU loading
 15% higher
 Browsing may consume
up to 30% more energy
2010/11/30
26
Evaluation
 Server Scalability
 Dual-Core NB
 2.26GHz P8400 + 4G RAM
 Quad-Core
 2.40GHz Q6600 + 8G RAM
 Amazon EC2
2010/11/30
27
Evaluation
 Dynamic Taint Analysis
 X2-x2.5 slowdown
 If DTA applied to all replica
 Only roughly half of the instances reported in
Figure5
2010/11/30
28
Evaluation
 Overhead Imposed By Ptrace
 Compression (deflate_slow) consumes only 7.62%
 65% is spent in ptrace and waitpid
 Solution: move to kernel
2010/11/30
29
Evaluation
2010/11/30
30
Related Work
 Malkhi et al.
 Secure execution of java applets using a remote
playground
 Ripley: automatically securing web 2.0
applications through replicated execution
 CloudCloud
 Acceleration
 SmartSiren
 Antivirus in smartphones
2010/11/30
31
Related Work
 VirusMeter
 Kirin
2010/11/30
32
Conclusion
 Attack detection on a remote server in the
cloud
 No limit on the number of attack detection
techniques
 Transmission overhead is kept below
2.5KiBps
2010/11/30
33