Software Security
Information Flow for Android Apps
Erik Poll Digital Security group Radboud University Nijmegen
1
Recap typing Recall from earlier lectures & lecture notes (chapter 3):
Typing is a great way to prevent certain kinds of bugs
Type-safety (aka type-soundness) makes this even better
by making certain kinds of bugs less likely
by making make certain kinds of flaws impossible
Sound type system can provide the basis for more language-level safety guarantees, such as sand-boxing (ie. code-based access control inside one program), immutable objects, …
2
Recap information flow & typing Recall from last week & lecture notes (chapter 5):
Typing can be used to track information flows between several levels
using a lattice of security levels
for integrity or for confidentiality
Such type systems can be overly restrictive
Preventing implicit flows is tricky if (... hi ...) { lo = ... } ; // not allowed (Hence s : ok t means s only writes to level t or higher)
Preventing termination- or timing-leaks even more so if (... hi ...) { ... } ; // not allowed
3
Java Annotations on Types &
4
Java’s type system is too weak? Java’s type system can catch certain errors boolean b = 2.0 + "hello"; but not all System.console().readLine();
int i = a[4];
possible NullPointer possible NullPointer or IndexOutOfBounds
rs = stmt.executeQuery(query); possible SQL injection?
5
Java types not expressive enough? Java’s type system can’t spot problem with int doubleLength(String s) {return s.length * 2; } ...
int j = doubleLength(null);
Who’s fault is this?
•
The programmer who wrote the code for doubleLength ?
• Or the programmer who calls with doubleLength with null argument?
6
User-definable Java type annotations Programmer can declare annotations of the form @SomeAnnotation @SomeAnnotationWithElements(colour = "blue", age = "18") @SomeAnnotationWithOneElement("blue")
that can be added to source code • on declarations, eg of classes, fields, methods, ... public @Colour("green") class Grass {...}
private @Colour("red") int í; • on uses of types (since Java 8) new @Colour("green") List(...); 7
Annotation example: @NonNull and @Nullable
int doubleLength(@NonNull String s) {return s.length * 2; } ...
int j = doubleLength(null);
// this is wrong!
8
Annotation example: @NonNull and @Nullable
int doubleLength(@Nullable String s) {return s.length * 2; }
// this is wrong
...
int j = doubleLength(null);
9
Fancier examples You can combine type annotations with generics, eg @NonEmpty List
Warning: annotations on array types can be hard to read, eg
@NonNull String []
What could this mean? a non-null array of strings or an array of non-nulls strings? These are the sort of things you have to look up with the language manual. 10
Type annotations & pluggable type systems You can use annotations 1. just as informal documentation to help the programmer 2. to aid to some static analysis tool Or you can use annotations on types as real types, to improve (or refine) Java’s type system, by providing a type checker that checks them. • One can argue that this is just a special form of 2 above
The has been developed to make it easy to define such custom type checker (see http://CheckerFramework.org)
11
Annotation example: ensuring encrypted information void send(@Encrypted String msg) {...} @Encrypted String encrypt(String s, Key k) {...} ... @Encrypted String msg1 = ...;
send(msg1); // OK? String msg2 = ....; send(msg2); // OK?
send(encrypt(msg2,key)); // OK?
12
Annotation example: ensuring encrypted information void send(@Encrypted String msg) {...} @Encrypted String encrypt(String s, Key k) {...} ... @Encrypted String msg1 = ...;
send(msg1); // OK! String msg2 = ....; send(msg2); // Warning!
send(encrypt(msg2,key)); // OK!
13
Annotation example: ensuring encrypted information The (one-line) definition of the typechecker using the Checker framework
@Target(ElementType.TYPE_USE) @SubtypeOf(Unqualified.class)
public @interface Encrypted {}
14
SPARTA: Static Program Analysis for Reliable Trusted Apps
15
Type system for information flow in Java apps Collaborative Verification of Information Flow for a High-Assurance App Store by 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
CCS 2014
This paper presents SPARTA (Static Program Analysis for Reliable Trusted Apps) More info at http://www.cs.washington.edu/sparta 16
Context: current generation of app stores
• App stores have some approval process
• They have to approve hundreds of apps per day • Problem: all app stores have approved malware • Current best practice: remove malware when it is reported
17
Security worries in apps Malware can 1. steal user information (location, installed apps, ..) 2. steal user credentials (passwords, ...) 3. make premium calls or SMS
4. send SMS advertising 5. improve website rankings in search engine results 6. do something funny & (accidentially?) some purposeless destruction
7. ransomware
SPARTA can prevent 1-4 •
but not phishing as way to steal credentials, which is also a form of 2.
18
Better app stores offering higher assurance level • Could a specialised app store provide higher level of assurance? Eg for special categories of apps or users, such as – financial or medical apps, – corporate or government users • Could there be a business model in this? To make extra effort commercially viable or even profitable. • Bottlenecks: 1. what to check ? 2. how to check? 3. can this be done at reasonable cost (time & effort)?
19
SPARTA • Security type system for Android apps – to guarantee information flow policies, that rule out unwanted information leaks • Java annotations used to annotate code • Checker framework is used to type check these – but some manual checks for declassification, incl. manual checks for implicit flows in conditional statements • Collaborative verification, where 1. code developer does some work by adding annotations 2. human verifier runs checker & performs manual checks
20
Collaborative verification model • Developer provides app description
Information Flow Policy
1
Annotated Source Code 2
declassification justifications
3
• App store analysist 1. checks if information flow policy is acceptable (manually) 2. runs the type checker 3. checks the declassifications (manually) 21
What to check? Information flow policies! The target: preventing malware with unwanted information flows Information flow policies specified using sources and sinks, where information comes from or goes to Example sources
Example sinks
• • • •
• • • •
camera location information SMS reading the file system
the display the internet SMS sending the file system
• Many sources and sinks already occur as Android permissions • Some things can be both source and sink, eg. the file system 22
Android permissions vs information flow policies • An app can have Android permission to access – location information – internet connection – camera – file system • As an information flow policy, the app could only have permission to – save camera image to disk (ie not to send it over the internet) – save location to disk (intuition: together with image) – download updates over the internet connection This is much more fine-grained, but not perfect! 23
Example information flow policies READ_SMS
-> DISPLAY
USER_INPUT
-> CALL_PHONE
CAMERA
-> DISPLAY, DATA
LOCATION
-> INTERNET(maps.google.nl)
Sources and sinks may be parameterised.
Notation: -> is also written as ! in the paper
24
Transitivity & white-washing Transitive flows must be explicitly specified. So the policy CAMERA
-> FILESYSTEM
FILESYSTEM
-> INTERNET
must also include CAMERA -> INTERNET Idea: make it explicit that the camera can now whitewash data via file system. Parameters can be used to restrict transitivity, eg CAMERA FILESYSTEM("config/*")
-> FILESYSTEM("images/*") -> INTERNET
25
Information flow types: sources and sinks @Source
Where might this info come from?
@Sink
Where might this info go to?
These type annotations take a parameter (or element, in Java terminology). For example
@Source(CAMERA) - this info comes from, or might come from, the camera @Source(LOCATION) - this info might be location information @Sink(INTERNET) - this info might be sent over the internet
@Source(INTERNET,CAMERA) - this info might come from camera or internet
26
Example type annotations Suppose the Android API includes methods public static void sendToInternet(String s); public static String readGPS();
What would be good annotations of these methods ? public static void sendToInternet(@Sink(INTERNET) s); public static @Source(LOCATION)String readGPS();
27
Example typings Given the API methods void sendToInternet(@Sink(INTERNET) String message); @Source(LOCATION)String readGPS();
What would be a correct annotation of the app code below? String loc = readGPS(); sendToInternet(loc);
28
Example typings Given the API methods
API annotations are given and trusted
void sendToInternet(@Sink(INTERNET) String message); @Source(LOCATION)String readGPS();
What would be a correct annotation of the app code below? @Source(LOCATION)@Sink(INTERNET) String loc = readGPS(); sendToInternet(loc); app annotations are to be provided by app developer and are not trusted Based on the policy, some implicit source may be inferred if only sink is specified (and vv). 29
Is this code ok? @Source(SMS) String s = ... ; @Source(SMS,INTERNET) String t = s;
@Source(SMS)
@Sink(SMS,INTERNET) String msg1 = ...;
@Source(SMS,INTERNET) @Sink(SMS) String msg2 = msg1;
NB for mutable data structures you have to be careful!
30
Subtyping There is a natural subtype relation on types. For example, •
between @Source(SMS) and @Source(SMS,INTERNET)
•
between @Sink(SMS) and @Sink(SMS,INTERNET)
Which one is a subtype of the other?
31
Subtyping There is a natural subtyping relation on types. For example, @Source(SMS) is a subtype of @Source(SMS,INTERNET) @Sink(SMS,INTERNET) is a subtype of @Sink(SMS)
Note the opposite direction of the subtype relation for Sources and Sinks. • Recall that we also saw this in type systems for information flow, for reading information of some level vs writing information to a variable of some level
32
The subtype relation forms a lattice
@Source(ANY) = @Source{LOCATION, INTERNET, SMS, CAMERA, ...} 33
Subsumption The subtype relation gives rise to a subsumption rule in the type system. • Eg, if @Source(SMS) String s; then s also has type @Source(SMS,INTERNET)
Recall subtyping aka subsumption rule from last week & lecture notes e:t
t t‘
e : t'
34
Quiz: is this app code ok & does it meet policy? App code: @Source(LOCATION)@Sink(INTERNET)String loc = readGPS(); sendToInternet(loc);
Policy: LOCATION -> INTERNET
35
Quiz: is this app code ok & does it meet policy? App code: @Source(LOCATION)@Sink(INTERNET)String loc = readGPS(); sendToInternet(loc);
Policy: LOCATION -> SMS
LOCATION -> SMS,INTERNET
36
Quiz: is this app code ok & does it meet policy? App code: @Source(LOCATION)@Sink(SMS)String loc = readGPS(); sendToInternet(loc);
Policy: LOCATION -> SMS
37
Quiz: is this app code ok & does it meet policy? App code: @Source(LOCATION)@Sink(SMS)String loc = readGPS(); sendToInternet(loc);
Policy: LOCATION -> INTERNET
The code does meet the policy, but the app developer screwed up the annotations, so the type checker will complain!
38
Trickier cases & need for declassification: arrays String[] a; a[0] = readGPS(); a[1] = readSMS();
What would be a good annotation of the code above, using the parameter LOCATION and SMS?
39
Trickier cases & need for declassification: arrays @Source({LOCATION, SMS})String[] a; a[0] = readGPS(); a[1] = readSMS();
What would be a good annotation of the code above, using the parameter LOCATION and SMS? This is not the most accurate description, we `loose’ some information, namely that the two array elements have different types.
40
Trickier cases & need for declassification: arrays @Source({LOCATION, SMS})String[] a; a[0] = readGPS(); a[1] = readSMS(); String loc = array[0];
What would be a good annotation of the code above?
41
Trickier cases & need for declassification: arrays @Source({LOCATION, SMS})String[] a; a[0] = readGPS(); a[1] = readSMS(); @Source({LOCATION, SMS})String loc = array[0];
We would like to be more precise and write @Source(LOCATION) String loc = array[0];
but then the type checker will complain.
42
Trickier cases & need for declassification: arrays @Source({LOCATION, SMS}) String[] a; a[0] = readGPS(); a[1] = readSMS(); @SuppressWarnings("flow") // Always returns location data
@Source({LOCATION}) String loc = array[0];
App developer can surpress false positives.
But the human verifier will have to manually verify these!
43
Trickier cases & need for declassification: implicit flows @Source(USER_INPUT) long pin = getPINCode(); long i=0; while (true) { if (i == pin) { sendToInternet(i); } i++; } Approaches 1. naive approach, ignoring implicit flows, would be unsound, and allow leaking of the PIN code 2. classic, sound approach, as in lecture notes: in an if-statement you can only send stuff over the internet if all variables used in the guard can be sent over the internet. This becomes very restrictive
3. solution used in SPARTA: introduce a new sink CONDITIONAL 44
Trickier cases & need for declassification: implicit flows @Source(USER_INPUT) long pin = getPINCode(); long i=0; while (true) { if (i == pin) { sendToInternet(i); } i++; }
USER_INPUT -> CONDITIONAL
SPARTA approach to implicit flows • New sink CONDITIONAL • Flows to CONDITIONAL if classified information is used in a condition • Type analysis will warn about these • Human verifier will have to check these 45
Collaborative verification model • Developer provides app description
Information Flow Policy
1
Annotated Source Code 2
declassification justifications
3
• App store analysist 1. checks if information flow policy is acceptable 2. runs the type checker 3. manually checks the declassifications 46
Trusted Computing Base (TCB) What is in the Trusted Computing Base? And what not? • the Android OS, incl the Java VM • the type checker for annotations • the Java compiler & byte code verifier
• the annotations provided for the APIs • the human verifier
• not the annotations provided by the app developer
47
Trickier case: polymorphism & generics • Annotations interact with generics (aka parametric polymorphism), eg List myList;
• How to annotate a function (ie Java static method) such as static char[] stringToCharArray(String s) ? This function is polymorphic: it preserves any type annotation on the input.
Solution: in annotations you can quantify over all type annotations, using a special type annotation variable @PolySource @PolySource char[] stringToCharArray(@PolySource String s)
48
Relation with information flow by source code scanners The more ad-hoc data flow analysis done by Fortify (for tainted input data, ie for integrity instead of confidentiality) runs into similar issues as here, eg
• can information be white-washed by storing and then reading it from the file system? • how can we track information flows through arrays?
• how do we deal with implicit flows? • how do we deal with the API, and operations such as stringToCharArray, subString,...
• ... These are fundamental complications in any data flow analysis or information flow analysis! 49
Case study (see paper) • Analysis of 72 apps written by Red Team • Relatively low annotation burden: 6 annotations/100 loc • Relatively low auditing (ie human verifier) burden: 30 minutes/ kloc – but is this acceptable for several Mbytes of code?
• 96% of information flow related malware found (It’s hard to find in the paper what the problem with the remaining 4% is, but it is claimed that extensions discussed in 2.10 would fix them)
• This was 82% of all malware in these apps, as some malware behaviour was not about unwanted information flow
50
To read Collaborative Verification of Information Flow for a High-Assurance App Store by 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
CCS 2014
See link on course webpage.
51
