CS

 155   Spring  2014  

Program  Analysis  for  Security  

John  Mitchell  
So>ware  bugs  are  serious  problems  

Thanks:  Isil  and  Thomas  Dillig  

App  stores  
App  stores  
      How  can  you  tell  whether    
     so>ware  you  
–  Buy  
–  Develop    
–  Install  
     is  safe  to  run?  
 Cost  of  Fixing  a  Defect  

Development QA Release Maintenance

Credit: Andy Chou, Coverity

 Several  approaches  
•  Instrument  code  for  tesMng  
–  Heap  memory:  Purify  
–  Perl  tainMng      (informaMon  flow)  
–  Java  race  condiMon  checking  
•  Black-­‐box  tesMng  
–  Fuzzing  and  penetraMon  tesMng  
–  Black-­‐box  web  applicaMon  security  analysis  
•  StaMc  code  analysis  
–  FindBugs,  ForMfy,  Coverity,  MS  tools,  …  
7  
 Outline  
•  General  discussion  of  staMc  analysis  tools  
–  Goals  and  limitaMons  
–  Approach  based  on  abstract  states  
•  More  about  one  specific  approach  
–  Property  checkers  from  Engler  et  al.,  Coverity  
–  Sample  security-­‐related  results  
•  StaMc  analysis  for  of  Android  apps  

Slides  from:  S.  Bugrahe,  A.  Chou,  I&T  Dillig,  D.  Engler,  J.  Franklin,  A.  Aiken,  …  
 Manual  tesMng  
Entry   1   2   4   only  examines  
small  subset  of  
1   3   4   behaviors  
1   1   2   4   1   3   4  

1   2   4   1   3   4  
2   3  
1   2   3   1   2   4   1   3   4  

1   2   4   1   2   3   1   3   4  
4  
1   2   3   1   2   3   1   3   4  

1   2   4   1   2   4   1   3   4  
Exit  

So#ware  
.  .  .   Behaviors  

9
 Program  Analyzers  
analyze  large    
code  bases  

Code   Report     Type   Line  

1   mem  leak   324  
2   buffer  oflow   4,353,245   false  alarm  
Program   3   sql  injecMon   23,212  
Analyzer   4   stack  oflow   86,923  
5   dang  ptr   8,491   false  alarm  
Spec   …   …   …  
10,502   info  leak   10,921  

poten5ally    
reports  many   may  emit    
false  alarms  
warnings  
 Example  
•  Coverity  demo  video:  hcp://youtu.be/_Vt4niZfNeA    
•  ObservaMons  
–  Code  analysis  integrated  into  development  workflow  
–  Program  context  important:  analysis  involves  sequence  of  
funcMon  calls,  surrounding  statements  
–  This  is  a  sales  video:  no  discussion  of  false  alarms  
 StaMc  analysis  goals  
•  Bug  finding  
–  IdenMfy  code  that  the  programmer  wishes  to  
modify  or  improve  
•  Correctness  
–  Verify  the  absence  of  certain  classes  of  errors  

 
 Soundness,  Completeness  
Property   Defini5on  

Soundness   If  the  program  contains  an  error,  

the  analysis  will  report  a  warning.  
“Sound  for  reporMng  correctness”  

Completeness   If  the  analysis  reports  an  error,  the  

program  will  contain  an  error.  
“Complete  for  reporMng  correctness”  
 Complete   Incomplete  

Reports  all  errors  

Sound  

Reports  all  errors  

Reports  no  false  alarms   May  report  false  alarms  

Undecidable   Decidable  
Unsound  

May  not  report  all  errors   May  not  report  all  errors  
Reports  no  false  alarms   May  report  false  alarms  

Decidable   Decidable  
 Sound  
Modules  
Reported   Over-­‐approxima5on  of  
Error   Behaviors  

.  .  .  

False   approximaMon  is  too  coarse…  

Alarm   Behaviors  
…yields  too  many  false  alarms  

So#ware  
 Outline  
•  General  discussion  of  tools  
–  Goals  and  limitaMons  
–  Approach  based  on  abstract  states  
•  More  about  one  specific  approach  
–  Property  checkers  from  Engler  et  al.,  Coverity  
–  Sample  security-­‐related  results  
•  StaMc  analysis  for  Android  malware  
–  …  

Slides  from:  S.  Bugrahe,  A.  Chou,  I&T  Dillig,  D.  Engler,  J.  Franklin,  A.  Aiken,  …  
Does  this  program  ever  crash?  
entry  

X  ß  0  

Is  Y  =  0  ?  
yes   no  

X  ß  X  +  1   X  ß  X  -­‐  1  

Is  Y  =  0  ?  
yes   no  

Is  X  <  0  ?   exit  
yes   no  

crash  
Does  this  program  ever  crash?  
entry  

X  ß  0  

Is  Y  =  0  ?  
yes   no  

X  ß  X  +  1   X  ß  X  -­‐  1  

Is  Y  =  0  ?  
yes   no  

Is  X  <  0  ?   exit  
yes   no  

crash  
infeasible  path!  
…  program  will  never  crash  
Try  analyzing  without  approximaMng…  
entry  

X  ß  0  
X  =  0  

Is  Y  =  0  ?  
yes   no  
X  =  2
0  
1
X  ß  X  +  1   X  ß  X  -­‐  1  
X  =  3
1  
2
X  =  3
1  
2
Is  Y  =  0  ?  
X  =  3
1  
2 yes   no  

Is  X  <  0  ?   exit  
yes   no   X  =  3
1  
2

crash  
non-­‐termina5on!  
…  therefore,  need  to  approximate  
 dataflow  elements  

X  =  0   din  

X  ß  X  +  1   f   dout  =  f(din)  

X  =  1   dout  

dataflow  equa5on  
transfer  func5on  
X  =  0   din1  

X  ß  X  +  1   f1  
X  =  1   dout1  
dout1  =  f1(din1)  
X  =  1   din2   dout1  =  din2  
Is  Y  =  0  ?   f2  
dout2  =  f2(din2)  
X  =  1   dout2  
 dout1  =  f1(din1)  
din1   din2  
dout2  =  f2(din2)  
f1   f2  

dout1   dout2   djoin  =  dout1  ⊔ dout2  

djoin  
din3   djoin  =  din3  
f3  
dout3   dout3  =  f3(din3)  

least  upper  bound  operator  

Example:  union  of  possible  values  
What  is  the  space  of  dataflow  elements,  Δ?  
What  is  the  least  upper  bound  operator,  ⊔?  
Try  analyzing  with  “signs”  approximaMon…  
entry  

X  ß  0  
X  =  0  

Is  Y  =  0  ?  
yes   no  
X  =  0   X  =  0  
X  ß  X  +  1   X  ß  X  -­‐  1  
X  =  pos   X  =  neg  
X  =  T    
lost     Is  Y  =  0  ?  
precision   X  =  T     X  =  T    
yes   no  

Is  X  <  0  ?   exit  
yes   no   X  =  T    
X  =  T    

terminates...   crash  
…  but  reports  false  alarm  
…  therefore,  need  more  precision  
 X  =  T    

true  
X  ≠  neg   X  =  T    X  ≠  pos  

Y  =  0   Y  ≠  0  
X  =  pos   X  =  0   X  =  neg  

false  
X  =  ⊥  
X  =  ⊥  

refined  
signs  
signs  
laUce  
laUce   Boolean  formula  laUce  
Try  analyzing  with  “path-­‐sensiMve  signs”  approximaMon…  
entry  

X  ß  0  
true   X  =  0  

Is  Y  =  0  ?  
yes   no  
Y=0   X  =  0   X  =  0   Y≠0  
X  ß  X  +  1   X  ß  X  -­‐  1  
Y=0   X  =  pos   X  =  neg   Y≠0  
no  precision  loss  
Y=0   X  =  pos   Is  Y  =  0  ?  
Y≠0   X  =  neg   X  =  neg   Y≠0  
yes   no  
Y=0   X  =  pos  
Is  X  <  0  ?   exit  
refinement  
yes   no  
X  =  pos   Y=0  
terminates...   crash  
…  no  false  alarm  
…  soundly  proved  never  crashes  
 Outline  
•  General  discussion  of  tools  
–  Goals  and  limitaMons  
–  Approach  based  on  abstract  states  
•  More  about  one  specific  approach  
–  Property  checkers  from  Engler  et  al.,  Coverity  
–  Sample  security-­‐related  results  
•  StaMc  analysis  for  Android  malware  
–  …  

Slides  from:  S.  Bugrahe,  A.  Chou,  I&T  Dillig,  D.  Engler,  J.  Franklin,  A.  Aiken,  …  
 Bugs to Detect

Some examples
•  Crash Causing Defects •  Uninitialized variables
•  Null pointer dereference •  Invalid use of negative values
•  Use after free •  Passing large parameters by value
•  Double free •  Underallocations of dynamic data
•  Array indexing errors •  Memory leaks
•  Mismatched array new/delete •  File handle leaks
•  Potential stack overrun •  Network resource leaks
•  Potential heap overrun •  Unused values
•  Return pointers to local variables •  Unhandled return codes
•  Logically inconsistent code •  Use of invalid iterators

Slide  credit:  Andy  Chou  

28

 Example: Check for missing optional args

•  Prototype for open() syscall:

int open(const char *path, int oflag, /* mode_t mode */...);

•  Typical mistake:
fd = open(“file”, O_CREAT);

•  Result: file has random permissions

•  Check: Look for oflags == O_CREAT without mode

argument

29

 Example: Chroot protocol checker

•  Goal: confine process to a “jail” on the filesystem

−  chroot() changes filesystem root for a process
•  Problem
−  chroot() itself does not change current working directory

chroot() chdir(“/”)

open(“../file”,…) Error if open

before chdir

30

 TOCTOU

•  Race condition between time of check and use

•  Not applicable to all programs

check(“foo”) use(“foo”)

31

Tainting checkers

32

 Example code with function def, calls

#include <stdlib.h>
#include <stdio.h>

void say_hello(char * name, int size) {

printf("Enter your name: ");
fgets(name, size, stdin);
printf("Hello %s.\n", name);
}

int main(int argc, char *argv[]) {

if (argc != 2) {
printf("Error, must provide an input buffer size.\n");
exit(-1);
}
int size = atoi(argv[1]);
char * name = (char*)malloc(size);
if (name) {
say_hello(name, size);
free(name);
} else {
printf("Failed to allocate %d bytes.\n", size);
}
}

33

 Callgraph

main

atoi exit free malloc say_hello

fgets printf

34

 Reverse Topological Sort

8 main

atoi exit free malloc say_hello

3 7
4 5 6

Idea: analyze function fgets printf

before you analyze caller
2 1

35

 Apply Library Models

8 main

atoi exit free malloc say_hello

3 7
4 5 6

fgets printf
Tool has built-in summaries of
library function behavior 2 1

36

 Bottom Up Analysis

8 main

atoi exit free malloc say_hello

3 7
4 5 6

Analyze function using known fgets printf

properties of functions it calls
2 1

37

 Bottom Up Analysis

8 main

atoi exit free malloc say_hello

3 7
4 5 6

Analyze function using known fgets printf

properties of functions it calls
2 1

38

 Bottom Up Analysis

8 main

atoi exit free malloc say_hello

3 7
4 5 6

Finish analysis by analyzing all fgets printf

functions in the program
2 1

39

 Finding Local Bugs

#define SIZE 8
void set_a_b(char * a, char * b) {
char * buf[SIZE];
if (a) {
b = new char[5];
} else {
if (a && b) {
buf[SIZE] = a;
return;
} else {
delete [] b;
}
*b = ‘x’;
}
*a = *b;
}

40

 Control Flow Graph

char * buf[8];
Represent logical structure of
code in graph form
if (a)
a !a

b = new char [5]; if (a && b)

a && b !(a && b)
buf[8] = a; delete [] b;

*b = ‘x’;

*a = *b;

END

41

 Path Traversal
Conceptually: Analyze each path
Conceptually
through control graph separately
char * buf[8];
Actually Perform some checking
computation once per node;
if (a) combine paths at merge nodes
a !a

b = new char [5]; if (a && b)

a && b !(a && b)
buf[8] = a; delete [] b;

*b = ‘x’;

*a = *b;

END

42

 Apply Checking

Null pointers Use after free Array overrun

char * buf[8]; See how three checkers are run for this path

if (a)
!a • 
Checker
•  Defined by a state diagram, with state
if (a && b)
transitions and error states
!(a && b)
delete [] b; • 
Run Checker
•  Assign initial state to each program var
*b = ‘x’; •  State at program point depends on
state at previous point, program actions
•  Emit error if error state reached
*a = *b;

END

43

 Apply Checking
Null pointers Use after free Array overrun
char * buf[8];
“buf is 8 bytes”
if (a)
!a
if (a && b)
!(a && b)
delete [] b;

*b = ‘x’;

*a = *b;

END

44

 Apply Checking

Null pointers Use after free Array overrun

char * buf[8];
“buf is 8 bytes”
if (a)
!a “a is null”
if (a && b)
!(a && b)
delete [] b;

*b = ‘x’;

*a = *b;

END

45

 Apply Checking

Null pointers Use after free Array overrun

char * buf[8];
“buf is 8 bytes”
if (a)
!a “a is null”
if (a && b)
!(a && b) Already knew
delete [] b; a was null

*b = ‘x’;

*a = *b;

END

46

 Apply Checking

Null pointers Use after free Array overrun

char * buf[8];
“buf is 8 bytes”
if (a)
!a
“a is null”
if (a && b)
!(a && b)
delete [] b;
“b is deleted”
*b = ‘x’;

*a = *b;

END

47

 Apply Checking

Null pointers Use after free Array overrun

char * buf[8];
“buf is 8 bytes”
if (a)
!a “a is null”
if (a && b)
!(a && b)
delete [] b;
“b is deleted”
*b = ‘x’;
“b dereferenced!”
*a = *b;

END

48

 Apply Checking

Null pointers Use after free Array overrun

char * buf[8];
“buf is 8 bytes”
if (a)
!a “a is null”
if (a && b)
!(a && b)
delete [] b;
“b is deleted”
*b = ‘x’;
“b dereferenced!”
*a = *b;
No more errors
END reported for b

49

 False Positives

•  What is a bug? Something the user will fix.

•  Many sources of false positives

−  False paths
−  Idioms
−  Execution environment assumptions
−  Killpaths
−  Conditional compilation
−  “third party code”
−  Analysis imprecision
−  …

50

 A False Path

char * buf[8];

if (a)
a !a

b = new char [5]; if (a && b)

a && b !(a && b)
buf[8] = a; delete [] b;

*b = ‘x’;

*a = *b;

END

51

 False Path Pruning
Integer Range Disequality Branch

char * buf[8];

if (a)
!a
if (a && b)
a && b
buf[8] = a;

END

52

 False Path Pruning
Integer Range Disequality Branch

char * buf[8];

if (a)
!a “a in [0,0]” “a == 0 is true”
if (a && b)
a && b
buf[8] = a;

END

53

 False Path Pruning
Integer Range Disequality Branch

char * buf[8];

if (a)
!a “a in [0,0]” “a == 0 is true”
if (a && b)
a && b “a != 0”
buf[8] = a;

END

54

 False Path Pruning
Integer Range Disequality Branch

char * buf[8];
Impossible
if (a)
!a “a in [0,0]” “a == 0 is true”
if (a && b)
a && b “a != 0”
buf[8] = a;

END

55

 Environment Assumptions

•  Should the return value of malloc() be checked?

int *p = malloc(sizeof(int));
*p = 42;

OS Kernel: File server: Web application:

Crash machine. Pause filesystem. 200ms downtime

Spreadsheet: Game: IP Phone:

Lose unsaved changes. Annoy user. Annoy user.

Library: Medical device:

? malloc?!

56

 Statistical Analysis

•  Assume the code is usually right

int *p = malloc(sizeof(int)); int *p = malloc(sizeof(int));

*p = 42; if(p) *p = 42;

int *p = malloc(sizeof(int)); int *p = malloc(sizeof(int));

*p = 42; if(p) *p = 42;
3/4 1/4
deref int *p = malloc(sizeof(int)); int *p = malloc(sizeof(int)); deref
*p = 42; if(p) *p = 42;

int *p = malloc(sizeof(int)); int *p = malloc(sizeof(int));

if(p) *p = 42; *p = 42;

57

 Application to Security Bugs

•  Stanford research project

−  Ken Ashcraft and Dawson Engler, Using Programmer-Written
Compiler Extensions to Catch Security Holes, IEEE Security
and Privacy 2002
−  Used modified compiler to find over 100 security holes in Linux
and BSD
−  http://www.stanford.edu/~engler/
•  Benefit
−  Capture recommended practices, known to experts, in tool
available to all

58

 Sanitize integers before use

Warn when unchecked integers from untrusted

sources reach trusting sinks

Syscall Network copyin(&v, p, len)

param packet

any<= v <= any

v.tainted v.clean Use(v)
memcpy(p, q, v) array[v]
copyin(p,q,v) while(i < v)
copyout(p,q,v) …
ERROR

Linux: 125 errors, 24 false; BSD: 12 errors, 4 false

 Example security holes

•  Remote exploit, no checks

/* 2.4.9/drivers/isdn/act2000/capi.c:actcapi_dispatch */
isdn_ctrl cmd;
...
while ((skb = skb_dequeue(&card->rcvq))) {
msg = skb->data;
...
memcpy(cmd.parm.setup.phone,
msg->msg.connect_ind.addr.num,
msg->msg.connect_ind.addr.len - 1);

60

 Example security holes

•  Missed lower-bound check:

/* 2.4.5/drivers/char/drm/i810_dma.c */

if(copy_from_user(&d, arg, sizeof(arg)))

return –EFAULT;
if(d.idx > dma->buf_count)
return –EINVAL;
buf = dma->buflist[d.idx];
Copy_from_user(buf_priv->virtual, d.address, d.used);

61

 User-pointer inference

•  Problem: which are the user pointers?

−  Hard to determine by dataflow analysis
−  Easy to tell if kernel believes pointer is from user!
•  Belief inference
−  “*p” implies safe kernel pointer
−  “copyin(p)/copyout(p)” implies dangerous user ptr
−  Error: pointer p has both beliefs.
•  Implementation: 2 pass checker
inter-procedural: compute all tainted pointers
local pass to check that they are not dereferenced

62

 Results for BSD and Linux

•  All bugs released to implementers; most serious fixed

Linux BSD
Violation Bug Fixed Bug Fixed
Gain control of system 18 15 3 3
Corrupt memory 43 17 2 2
Read arbitrary memory 19 14 7 7
Denial of service 17 5 0 0
Minor 28 1 0 0
Total 125 52 12 12

63

 Outline  
•  General  discussion  of  tools  
–  Goals  and  limitaMons  
–  Approach  based  on  abstract  states  
•  More  about  one  specific  approach  
–  Property  checkers  from  Engler  et  al.,  Coverity  
–  Sample  security-­‐related  results  
•  StaMc  analysis  for  Android  malware  
–  …  

Slides  from:  S.  Bugrahe,  A.  Chou,  I&T  Dillig,  D.  Engler,  J.  Franklin,  A.  Aiken,  …  
 STAMP  Admission  System  
Sta5c  Analysis  
More  behaviors,  
fewer  details  
Static

STAMP

Dynamic
Alex  Aiken,  
Dynamic  Analysis   John  Mitchell,  
Fewer  behaviors,   Saswat  Anand,  
Jason  Franklin  
more  details   Osbert  Bastani,  
Lazaro  Clapp,  
Patrick  Mutchler,  
Manolis  Papadakis  
Analysis
Step 1 Convert bytecode to intermediate
format (called Quads)

Step 2 Compute call graph using Class

Hierarchy Analysis

Build an edge-labeled graph G by

Step 3
processing Quads of each class

Add new edges to G as per a set

Step 4
of rules until no rules apply
 Data Flow Analysis

Source: sendSMS()
getLoc() Sink: SMS
Location

sendInet() Sink: Internet

Location SMS Location Internet

•  Source-to-sink flows
o  Sources: Location, Calendar, Contacts, Device ID etc.
o  Sinks: Internet, SMS, Disk, etc.
 Data Flow Analysis in Action

•  Malware/Greyware Analysis
o  Data flow summaries enable enterprise-specific policies

•  API Misuse and Data Theft Detection

Source: Send
FB API Sink: Internet
FB_Data Internet

•  Automatic Generation of App Privacy Policies

o  Avoid liability, protect consumer privacy Privacy Policy
This app collects your:
Contacts

•  Vulnerability Discovery Phone Number

Address

Source:
Web SQL Stmt Sink: SQL
Untrusted_Data
 Challenges
•  Android is 3.4M+ lines of complex code
o  Uses reflection, callbacks, native code

•  Scalability: Whole system analysis impractical

•  Soundness: Avoid missing flows
•  Precision: Minimize false positives
STAMP Approach
Too expensive!

App App •  Model Android/Java

o  Sources and sinks
o  Data structures
o  Callbacks
Models
o  500+ models

Android
•  Whole-program analysis
STAMP

o  Context sensitive
OS

HW
 Building Models
•  30k+ methods in Java/Android API
o  5 mins x 30k = 2500 hours

•  Follow the permissions

o  20 permissions for sensitive sources
§  ACCESS_FINE_LOCATION (8 methods with source annotations)
§  READ_PHONE_STATE - (9 methods)
o  4 permissions for sensitive sinks
§  INTERNET, SEND_SMS, etc.
Identifying Sensitive Data

android.Telephony.TelephonyManager:  String  getDeviceId()  

•  Returns device IMEI in String

•  Requires permission GET_PHONE_STATE
@STAMP(
SRC ="$GET_PHONE_STATE.deviceid",
SINK ="@return"
)
Data We Track (Sources)

•  Account  data  
•  Audio  
•  Calendar  
•  Call  log   30+ types of
•  Camera   sensitive data
•  Contacts  
•  Device  Id  
•  Location  
•  Photos  (Geotags)  
•  SD  card  data  
•  SMS  
Data Destinations (Sinks)

•  Internet  (socket)  
•  SMS  
•  Email   10+ types of
•  System  Logs   exit points
•  Webview/Browser  
•  File  System  
•  Broadcast  Message  
Currently Detectable Flow Types

396  Flow  Types  

Unique  Flow  Types  =  Sources  x  Sink  

 Example Analysis
Contact Sync for Facebook (unofficial)

Description:
This application allows you to synchronize
your Facebook contacts on Android.

IMPORTANT:
* "Facebook does not allow [sic] to export phone
numbers or emails. Only names, pictures and
statuses are synced."
* "Facebook users have the option to block one or all
apps. If they opt for that, they will be EXCLUDED
from your friends list."

Privacy Policy: (page not found)

 Contact Sync Permissions
Category Permission Description

Your Accounts AUTHENTICATE_ACCOUNTS Act as an account authenticator

MANAGE_ACCOUNTS Manage accounts list

USE_CREDENTIALS Use authentication credentials

Network Communication INTERNET Full Internet access

ACCESS_NETWORK_STATE View network state

Your Personal Information READ_CONTACTS Read contact data

WRITE_CONTACTS Write contact data

System Tools WRITE_SETTINGS Modify global system settings

WRITE_SYNC_SETTINGS Write sync settings (e.g. Contact sync)

READ_SYNC_SETTINGS Read whether sync is enabled

READ_SYNC_STATS Read history of syncs

Your Accounts GET_ACCOUNTS Discover known accounts

Extra/Custom WRITE_SECURE_SETTINGS Modify secure system settings

Possible Flows from Permissions
Sources Sinks
READ_CONTACTS INTERNET

READ_SYNC_SETTINGS
WRITE_SETTINGS

READ_SYNC_STATS WRITE_CONTACTS

GET_ACCOUNTS WRITE_SECURE_SETTINGS

INTERNET WRITE_SETTINGS
Expected Flows
Sources Sinks
READ_CONTACTS INTERNET

READ_SYNC_SETTINGS
WRITE_SETTINGS

READ_SYNC_STATS WRITE_CONTACTS

GET_ACCOUNTS WRITE_SECURE_SETTINGS

INTERNET WRITE_SETTINGS
Observed Flows

Source: Write Sink:

FB API Contacts
FB_Data Contact_Book

Read Source:
Send Internet Sink: Internet
Contacts Contacts
 Example  Study:  Mobile  Web  Apps  
•  Goal  
IdenMfy  security  concerns  and  vulnerabiliMes  
specific  to  mobile  apps  that  access  the  web  using  an  
embedded  browser  
 
•  Technical  summary  
•  WebView  object  renders  web  content  
•  methods  loadUrl,  loadData,  loadDataWithBaseUrl,  postUrl  
•  addJavascriptInterface(obj,  name)  allows  JavaScript  code  
in  the  web  content  to  call  Java  object  method  name.foo()  
 Summary  
•  Analyze  a  dataset  of  737,828  Android  apps    
•  Found  large  number  of  apps  contain  severe  vulnerabiliMes    
•  37,418  apps  are  vulnerable  to  a  remote  code  execuMon  
exploit  when  run  on  any  Android  device,  because  of  security  
oversight  in  older  versions  and  slow  adopMon  of  safe  versions  
•  45,689  apps  are  vulnerable  to  a  remote  code  execuMon  
exploit  when  run  on  73%  of  the  in-­‐use  Android  devices.    
•  Offer  recommendaMons  for  developers  who  wish  to  avoid  
these  vulnerabiliMes.  
 Origin  Severity  

•  Severity  of  exploits  in  apps  that  include  Bridge  Objects  and  
can  navigate  to  content  belonging  to  untrusted  origins.  
 HTTP  Severity  

•  Severity  of  Bridge  Object  exploits  in  apps  that  load  content  
over  HTTP.  
 SSL  Error  Prevalence  

•  Prevalence  of  apps  that  can  or  must  ignore  SSL  errors  based  
on  implementaMons  of    onReceivedSslError  
 SSL  Error  Severity  

•  Severity  of  Bridge  Object  exploits  in  apps  that  must  ignore  SSL  
cerMficate  errors.  
 Lecture Summary

•  General discussion of tools

− Fundamental limitations
− Basic method based on abstract states
•  More details on one specific method
− Property checkers from Engler et al., Coverity
− Sample security-related results
•  Static analysis for Android malware
− …

Slides from: S. Bugrahe, A. Chou, I&T Dillig, D. Engler, J. Franklin, A. Aiken, …