Georgios PortokalidisColumbia University Philip HomeburgVrije Universiteit Kostas AnagnostakisNiometris R&D Herbert BosVrije Universiteit 2010/11/30 1

Paranoid Android? 2010/11/30 2 Click this album to play this song …

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 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-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 ptraceptrace  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 2010/11/ B/s 121B/s

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 P G RAM  Quad-Core  2.40GHz Q G 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