collaborative verification of information flow for a high ...mernst/pubs/infoflow-ccs2014-sli… ·...

Collaborative Verification of Information Flowfor a High-Assurance App Store

Michael D. Ernst, René Just, Suzanne Millstein, Werner Dietl*,Stuart Pernsteiner, Franziska Roesner, Karl Koscher, Paulo Barros,Ravi Bhoraskar, Seungyeop Han, Paul Vines, and Edward X. Wu

University of Washington

*University of Waterloo

November 6, 2014

Introduction Approach Evaluation Conclusion

Current commercial app stores

Approval processSeveral hundred

new apps per day

René Just, UW CSE Collaborative Verification of Information Flow for a High-Assurance App Store 1/24




new apps per day

Problem: Every major app store has approved malware!





new apps per day

Problem: Every major app store has approved malware!

Best-effort solution: Malware removed when encountered



High-assurance app stores

Needed in multiple domainsI Government app stores (e.g., DoD)I Corporate app stores (e.g., financial sector)I App stores for medical apps

Require stronger guaranteesI Verified absence of (certain types of) malware

Verification is costlyI Effort is solely on app store sideI Analyst needs to understand/reverse-engineer the app

Our solution: Collaboratively verify absence of malware

Our focus: Information-flow malware



Example: Information-flow malware

App Permissions

Sudoku

Read locationInternet




App Permissions

Sudoku


Camera





App Permissions Information flow

Sudoku


Camera


Location →Internet





Sudoku


Camera



Map






Sudoku


Camera



Map



Location →BadGuy.com





Sudoku


Camera



Map



Location →BadGuy.com

Prevent malware using aninformation flow type-system



Approach: Overview

Collaborative verification modelI Leverage but don’t trust the developer

Information Flow Type-checker (IFT)I Finer-grained permission model for AndroidI False positives and declassificationsI Implicit information flow

EvaluationI Effectiveness: Effective for real malware in real appsI Usability: Low annotation and auditing burden



Collaborative verification model

Developer provides

Annotatedsource code

Appdescription




Developer provides

Informationflow policy

High-level description ofinformation flows in app(LOCATION -> INTERNET)


Appdescription

Declassificationjustifications




Developer provides



Appdescription


App store verifies




Developer provides



Appdescription


App store verifies

Analyst verifies:acceptable behavior

1




Developer provides



Appdescription


App store verifies


1

Type checker verifies:annotations consistent

2




Developer provides



Appdescription


App store verifies


1


2

Analyst verifies:declassifications

3




Developer provides



Appdescription


App store verifies


1


2


3

Developer and analyst do tasks that are easy for them



Verification of information flow






Information flow policy

High-level description of permitted information flows

READ_SMS -> INTERNET

READ_CLIPBOARD -> DISPLAY

USER_INPUT -> CALL_PHONE

ACCESS_FINE_LOCATION -> INTERNET(maps.google.com)









Source flows to Sink





READ_SMS -> INTERNETREAD_CLIPBOARD -> DISPLAY

USER_INPUT -> CALL_PHONEACCESS_FINE_LOCATION -> INTERNET(maps.google.com)


Not sufficient tomodel information flow!

Sources and SinksI Default Android permissions (145)






READ_CLIPBOARD -> DISPLAYUSER_INPUT -> CALL_PHONE



Sources and SinksI Default Android permissions (145)I Additional sensitive resources (28)










Sources and SinksI Default Android permissions (145)I Additional sensitive resources (28)I Parameterized permissions



Information flow types: sources and sinks

@SourceWhere might a value come from?@SinkWhere might a value flow to?





void sendToInternet(String message);

String readGPS();

Android API





void sendToInternet(String message);

String readGPS();

Android APITo Internet





void sendToInternet(@Sink(INTERNET)String message);

String readGPS();

Android API






String readGPS();

Android API

From Location






@Source(LOCATION)String readGPS();

Android API







Android API

String loc = readGPS();

sendToInternet(loc);

App code







Android API

@Source(LOCATION)@Sink(INTERNET)String loc = readGPS();


App code







Android API



App code

API annotations are pre-verified

Developer annotations are not trusted



Type hierarchy for sources and sinks

@Source(ANY)

@Source({SMS, LOCATION})

@Source(SMS) @Source(LOCATION)

@Source({})

@Sink({})

@Sink(INTERNET) @Sink(SMS)

@Sink({INTERNET, SMS})

@Sink(ANY)




@Source(ANY)



@Source({})

@Sink({})



@Sink(ANY)

@Source(ANY) ≡ @Source({SMS, LOCATION, INTERNET, ...})




@Source(ANY)



@Source({})

@Sink({})



@Sink(ANY)

@Source(SMS)String sms = ...;@Source({SMS, LOCATION})String smsLoc = sms;




@Source(ANY)



@Source({})

@Sink({})



@Sink(ANY)

@Source(SMS)String sms = ...;@Source(LOCATION)String loc = sms;




@Source(ANY)



@Source({})

@Sink({})



@Sink(ANY)




@Source(ANY)



@Source({})

@Sink({})



@Sink(ANY)

@Sink({INTERNET, SMS})String toInetSms;@Sink(SMS)String toSms = toInetSms;




@Source(ANY)



@Source({})

@Sink({})



@Sink(ANY)

@Sink(SMS)String toSms;@Sink(INTERNET)String toInet = toSms;



Information Flow Type-checker (IFT): Overview


Guarantees of type-checking1. Annotations are consistent with code (type correctness)

2. Annotations are consistent with flow policy

No undisclosed information flows in app



Information Flow Type-checker (IFT): Overview


Android APIApp code Flow policy

Guarantees of type-checking1. Annotations are consistent with code (type correctness)

2. Annotations are consistent with flow policy

No undisclosed information flows in app



Information Flow Type-checker (IFT): Example


LOCATION -> INTERNET

Flow policy



App code






Flow policy


sendSms(loc);

App code






Flow policy


sendSms(loc);

App code

Incompatible sinks:INTERNET 6<: SMS






Flow policy

@Source(LOCATION)@Sink(SMS)String loc = readGPS();

sendSms(loc);

App code






Flow policy

@Source(LOCATION)@Sink(SMS)String loc = readGPS();

sendSms(loc);

App code

Forbidden flow:LOCATION -> SMS



False positives and declassifications

@Source({LOCATION, SMS})String [] array;array[0] = readGPS();array[1] = readSMS();

@Source(LOCATION)String loc = array[0];

App code

DeclassificationsI Developer can suppress false-positive warningsI App store employee verifies each declassification






App code

@Source(LOCATION)







App code

@Source(LOCATION)

@Source(LOCATION, SMS)





@Source({LOCATION, SMS})String [] array;array[0] = readGPS();array[1] = readSMS();@SuppressWarnings("flow") // Safe: returns location data@Source(LOCATION)String loc = array[0];

App code




Reducing false positives

@Source({LOCATION, SMS})String value;if (...) {value = readSMS();...}...

App code

value: @Source(SMS)

value: @Source({LOCATION, SMS})

Flow sensitivityI Type refinement with intra-procedural data flow analysis

Context sensitivityI Polymorphism (e.g., String operations, I/O streams, etc.)

Indirect control flowI Constant value propagationI Reflection analysisI Intent analysis




@Source({LOCATION, SMS})String value = ...;String substring = value.substring(0,8);

App code

Returns @Source({LOCATION, SMS})






Implicit information flow

@Source(USER_INPUT)long creditCard = getCard();long i=0;while (true) {if (++i == creditCard) {sendToInternet(i);

}}

App code





}}

App code

Card number implicitly leaked

Classic approach (Denning and Denning, CACM’77)I Taint all computations in dynamic scopeI Over-tainting may lead to taint explosion





}}

App code

USER_INPUT -> CONDITIONAL

Our approach: Prune irrelevant conditionsI Add additional sink CONDITIONALI Type-checker warning for conditions with sensitive source





}}

App code

USER_INPUT -> CONDITIONAL

Our approach: Prune irrelevant conditionsI Add additional sink CONDITIONALI Type-checker warning for conditions with sensitive source

Analyst must manually verifyI Analyst is aware of contextI No need to analyze dynamic scope for irrelevant conditions

(e.g., null checks, malicious conditions, or trigger)René Just, UW CSE Collaborative Verification of Information Flow for a High-Assurance App Store 16/24


Evaluation: Overview

Are our permission model and type system effective?I Adversarial Red Team challengeI Evaluation of effectiveness for real malware

Is our approach effective and efficient in a time-constrained set up?I Control team studyI Comparison of effectiveness and efficiency to control team

Is our verification model applicable for real-world apps?I Usability study with annotators and auditorsI Evaluation of annotation and auditing burden

Apps are not pre-annotated



Adversarial Red Team challenge

SetupI 5 independent Red TeamsI 72 Android apps (47 malicious with information-flow malware)I 8,000 LOC and 12 permissions per app on average

Results for 47 malicious apps

Android permissionsAdditional Sources and SinksParameterized permissionsUndetected

4%

20%

36%

40%

I 96% overall detection rate — 4% require modeling ofinformation flow paths (LOCATION -> ENCRYPT -> INTERNET)

I 60% of apps require our finer-grained sources and sinks



Control team study

SetupI Control team using dynamic and static analysis toolsI 18 Android apps (13 malicious)I 7,000 LOC and 16 permissions per app on average

Results

Detection rate Analysis time0

20

40

60

80

100

Rat

ioin

%

Control



Usability study

SetupI 2 groups acting as annotators and auditorsI 11 Android apps (1 malicious)I 900 LOC and 12 permissions per app on average

Annotation burdenI 96% of type annotations are inferredI Annotations required: 6 per 100 lines of codeI Annotation time: 16 minutes per 100 lines of code

Most time spent on reverse engineering



Usability study

DeclassificationsI 50% of apps had no declassificationsI On average 3 declassification per 1,000 lines of code

IFT’s features effectively reduce false positives

Auditing burdenI Overall review time: 3 minutes per 100 lines of codeI 35% of time: review the flow policyI 65% of time: review declassifications & conditionals

Only 23% of conditionals needed to be reviewed



Related work: Information flow

Jif (Myers, POPL’99)

I A security-typed language (incompatible Java extension)I Supports dynamic checks and focuses on expressiveness

FlowDroid (Arzt et al., PLDI’14), SuSi (Rasthofer et al., NDSS’14)

I FlowDroid propagates sources and sinks found by SuSiI SuSi classifies Android API methods using machine learning

IFT makes static verification of Android apps practicalI Finer-grained sources and sinks at type levelI Compiler plug-in using standard Java type annotations



Related work: Collaborative verification model

Verifying browser extensionsI IBEX (Guha et al., S&P’11)

I Verification of Fine (ML dialect) against complex policiesI Lerner et al., ESORICS’13

I Verification of private browsing using annotated JavaScript

IFT verifies information flow in Android appsusing a high-level flow policy

Automated policy verificationI Crowd-sourcing (Agarwal & Hall, MobiSys’13)I Natural language processing (Pandita et al., USENIX’13)I Clustering (Gorla et al., ICSE’14)

Could aid manual verification of flow policies



ConclusionsDeveloper provides



Appdescription


App store verifies


1


2


3


Android APIApp code Flow policy

Collaborative verification modelI Low overall verification effort for

developer and app store analystI IFT combined with other analyses

Information Flow Type-checker (IFT)I Context and flow-sensitive type systemI Fine-grained model for sources and sinksI High-level information flow policy

EvaluationI Detected 96% information-flow malwareI Low annotation and auditing burdenI Low false-positive rate

Android permissionsAdditional Sources and SinksParameterized permissionsUndetected

4%

20%

36%

40%

https://www.cs.washington.edu/sparta


https://www.cs.washington.edu/sparta

collaborative verification of information flow for a high ...mernst/pubs/infoflow-ccs2014-sli… ·...

Documents