37
Java language-based security (in general and for mobile phones in particular) Erik Poll Digital Security group Radboud University Nijmegen

Java language-based security (in general and for mobile phones in particular)

  • Upload
    luz

  • View
    23

  • Download
    0

Embed Size (px)

DESCRIPTION

Java language-based security (in general and for mobile phones in particular). Erik Poll Digital Security group Radboud University Nijmegen. mobile code. extensible application P comprising various (possibly less trusted ) extensions. P. Q. Internet. Code extension. OS. Resources. - PowerPoint PPT Presentation

Citation preview

Page 1: Java language-based security (in general and for mobile phones in particular)

Java language-based security(in general and for mobile phones in particular)

Erik PollDigital Security group

Radboud University Nijmegen

Page 2: Java language-based security (in general and for mobile phones in particular)

2

mobile code

• extensible application P comprising various (possibly less trusted) extensions

Resources

OS

InternetInternet

P

Code extension

Q

Page 3: Java language-based security (in general and for mobile phones in particular)

3

Example: browser plugin

Resources

OS

InternetInternet

Firefox

Browser plugin

libraries

Page 4: Java language-based security (in general and for mobile phones in particular)

4

Example: Java enabled mobile phones

Mobile phone

JVM

InternetInternet

midlet1

code download APIs

midlet2

midletn

Page 5: Java language-based security (in general and for mobile phones in particular)

5

Need for safe programming language

• Some 'modules' are less trusted than others • This requires a 'safe' programming language:

– which can restrict the way one (less trusted) component can affect another (more trusted) component

Eg• (untrusted) Java code executing on (trusted) Java platform • C# code executing on .NET platform• code of various sources executed on same platform, eg

– applet in browser, – midlet on mobile phone– driver in operating system?

Page 6: Java language-based security (in general and for mobile phones in particular)

6

Language-based security in Java

Java provides• type system

– enforced by static type checking & runtime checks– includes visibility modifiers: private, protected, public

• sandboxing– using stack inspection aka stack walking

that provide• type safety and memory safety• code-based access controleven in the presence of untrusted - buggy or

malicious - code

Page 7: Java language-based security (in general and for mobile phones in particular)

7

Java language guarantees – part I

VM

applet B

APIs

JRE(Java

Runtime Environmen

t) hardware (CPU + peripherals)

SecurityManager

ClassLoader

package C applet A

• applet A can only access visible methods & fields• eg not to private fields

• no pointer arithmetic to access memory "illegally"

Page 8: Java language-based security (in general and for mobile phones in particular)

8

Java language guarantees – part II

VM

applet B

APIs

JRE(Java

Runtime Environmen

t) hardware (CPU + peripherals)

SecurityManager

ClassLoader

package C applet A

• if applet A accesses a public API method, stack inspection restrictions may restrict this

• even if untrusted applet A tricks trusted applet B into doing this

Page 9: Java language-based security (in general and for mobile phones in particular)

9

• Buffer overflows are built-in vulnerability in some programming languages– pointer arithmetic, lack of array bounds checks,

and lack of type safety cause problems• Java is immune to this to a large extent, provided

– no use of Java native interface– no VM vulnerability– no flaw in type checker

• bytecode verifier on some phones known to be broken....

• Does this mean Java does not have vulnerabilities?

Page 10: Java language-based security (in general and for mobile phones in particular)

10

Attacking Java security (1): typing

• The sandbox relies on typing:– if type system is not sound, you can escape

the sandbox– there may bugs in the bytecode verifier

(bcv), which checks type correctness. These may be exploitable...

Page 11: Java language-based security (in general and for mobile phones in particular)

11

Attacking Java Security (2): native code

Original release date: January 22, 2007 Source: US-CERT Overview The Sun Java Runtime Environment(JRE) contains

multiple vulnerabilities that can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. Exploit code is publicly available. Vulnerability Note VU#149457

Sun Java JRE vulnerable to arbitrary code execution via an undetermined error

Two buffer overflow vulnerabilities in the Sun JRE may independently allow an untrusted applet to elevate its privileges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet.

Vulnerability Note VU#388289 Sun Microsystems Java GIF image processing buffer

overflow ...

Page 12: Java language-based security (in general and for mobile phones in particular)

12

Attacking Java security (3)

• The sandbox relies on correctness of

– java.lang.Classloader – java.lang.SecurityManager– java.lang.String– ...

Implementation bugs in these may be exploited...

Page 13: Java language-based security (in general and for mobile phones in particular)

13

Security flaw in code signing check (Magic Coat)

JavaSoft’s implementation of JDK1.1.1

package java.lang; public class Class { private String[] signers; /** Obtain list of signers of given class */ public String[] getSigners() { return signers; }

Can you spot the fatal security flaw?

Page 14: Java language-based security (in general and for mobile phones in particular)

14

Security flaw in code signing check (Magic

Coat)

• Absence of pointer arithmetic in Java does not rule out all problems with pointers.

• Ways to prevent this kind of bugs is an active area of research– goal: (type) system that can enforce some

alias control, confinement, encapsulation, ownership of references, ...

Page 15: Java language-based security (in general and for mobile phones in particular)

15

fields should be final (for thread-

safety)

array should be cloned to prevent representation exposure which allows unauthorised changes

Spot the defect in java.lang.String

package java.langpublic class String{ public char[] contents; public int offset, len; // idea: String is content[offset ... offset+len] String() {contents=null; offset=0; len=0;} String(char[] a) { contents = a; offset = 0; len = a.len;} String substring(int take) { if (take<=0) throw new NegativeSizeException(); String s = new String(); s.content=this.content; s.offset=0; s.len=Math.min(take,s.len); return s; }int getLength() { return len; } ...

class should be final to prevent

malicious subclasses

fields should be not be public to prevent

unauthorised changes, ie.

preserve integrity

Page 16: Java language-based security (in general and for mobile phones in particular)

16

Programming guidelines

Even if • type system is sound• type checker that implements it is correct• sandboxing is sound & implemented correcty

– ie no exploitable bugs in platfrom API classes like java.lang.Class, java.lang.SecurityManager

• sandboxing policy file is correcta particular Java applet may still be vulnerable to attacks

by untrusted codeProgramming guidelines have been proposed to rule out

known vulnerabilities• eg no public fields, ...

Page 17: Java language-based security (in general and for mobile phones in particular)

17

Java security programming guidelines

Online sources • Twelve rules by McGraw & Felten• Java secure programming HOWTO by Wheeler• ....

Note the context of these rules: they are for • applications that are – or may someday be – extended

with less trusted or untrusted code• API components that are by definition extended with

less trusted code

Page 18: Java language-based security (in general and for mobile phones in particular)

18

Java-enabled mobile phones MIDP

• aka J2ME (Java 2 Micro Edition), MIDP (Mobile Information Device Profile), with CLDC (Connected Limited Device

Configuration) API

• special API functionality– eg. support for sms:// as well as http://

• fine-grained sandboxing of applications, called midlets

Page 19: Java language-based security (in general and for mobile phones in particular)

19

J2ME MIDP security model

• sandbox offering fine-grained access control to "dangerous" functionality– dangerous = costs money, eg. using network to

phone or sms• code is trusted or not depending on digital signatures • trusted code can use network,• untrusted code is denied network access,• semi-trusted code has to ask user permission

– via pop-up message– permission may have to be asked only once, once

per session, or once per sms, depending how trusted the code

Page 20: Java language-based security (in general and for mobile phones in particular)

20

Midlet sandboxing

• Midlet has to be given permission to– access network– send sms– read PIM data (eg phonebook)– ...

• Permissions can be given– without any restrictions, or– with added restriction to ask the user

• once for every single event, or• once for every program run, or• only once for the lifetime of the midlet

Page 21: Java language-based security (in general and for mobile phones in particular)

21

mobile phone application security threats?

• malicious midlets making expensive calls, sending expensive sms messages, subscribing to sms services

• SMS spam by rogue midlets• stealing confidential data: phone book or diary content,

location data– unwanted information flow

• Denial-of-Service• X-rated contents, eg via backdoor in game

• ...Telecom providers want to avoid malicious or

buggy midlets that cause problems – costs them money and loses them

customers!

Page 22: Java language-based security (in general and for mobile phones in particular)

22

MIDP security bugs

• Phenoelit attack midlet on Siemens SS55 phone– creates race condition to let user unwittingly authorise SMS text message OK to send

SMS to 6492?Do you want to

play game?

Page 23: Java language-based security (in general and for mobile phones in particular)

23

limits of MIDP security model

But even without such bugs in platform

User cannot make security decisions• user gets confused• will press ok anyway• can be tricked ot tempted into making bad decisions• can't recognize expensive numbers• can't spot information leaking• ...as illustrated by the Mobius game

Page 24: Java language-based security (in general and for mobile phones in particular)

24

limits of MIDP security model

• Provider might want to certify compliance with richer security policies, eg– midlet will only dial to numbers beginning with 06 or

+316– midlet will only dial number supplied by user or taken

from phone book– midlet will not calculate phone number

• eg dial((5*x+y)/2); is very suspicious code– midlet will send at most 3 SMS – ...

• Can we make such policies precise?• Can we enforce these policies statically?

Page 25: Java language-based security (in general and for mobile phones in particular)

25

Policy for #SMS in JML specifications

public class Connection {

//@ static ghost int smsCount = 0;

//@ ensures smsCount == \old(smsCount) + 1;

public void sendSMS(/*@ non_null @*/ String number, /*@ non_null @*/ String message);

}

public class Connection {

//@ static ghost int smsCount = 0;

//@ ensures smsCount == \old(smsCount) + 1;

public void sendSMS(/*@ non_null @*/ String number, /*@ non_null @*/ String message);

}

public class Example {

//@ ensures APIClass.smsCount == \old(APIClass.smsCount)+2;

public void oneSMS() {

connection.sendSMS("+31612345678, "Hello");

connection.sendSMS("+31612345678, "Goodbye");

} }

public class Example {

//@ ensures APIClass.smsCount == \old(APIClass.smsCount)+2;

public void oneSMS() {

connection.sendSMS("+31612345678, "Hello");

connection.sendSMS("+31612345678, "Goodbye");

} }

Page 26: Java language-based security (in general and for mobile phones in particular)

26

JavaVerified

current practicefor describingbehaviour ofmidlets:graph showingscreens & transitionsbetween them

conformance checkedby testing

Page 27: Java language-based security (in general and for mobile phones in particular)

27

midlet navigation graph

added:sensitive APIcalls

Page 28: Java language-based security (in general and for mobile phones in particular)

28

Conformance to navigation graphs

• We want to translate such navigation graphs to JML

• This formal model could be used to prove that midlet behaves as specified in the graph– using program verification tool, eg ESC/Java2

• It could also be used for model-based testing

• Big challenge: midlet code is multi-threaded– program verification tools for multi-threaded

code still in their infancy

Page 29: Java language-based security (in general and for mobile phones in particular)

Lighterweight mechanism than program specification & verification

than JML:

Java tags

Page 30: Java language-based security (in general and for mobile phones in particular)

30

Spot the defect

{ ... if (spec!=null) f.add(spec); if(isComplete(spec)) prefs.add(spec);....}

boolean isComplete(Preference spec){ return spec.getColorKey() != null && spec.getColorValue() != null && spec.getTextKey() != null;}

isComplete should not

get a null argument

Page 31: Java language-based security (in general and for mobile phones in particular)

31

Spot the defect

{ ... if (spec!=null) f.add(spec); if(isComplete(spec)) prefs.add(spec);....}

boolean isComplete(@NonNull Preference spec){ return spec.getColorKey() != null && spec.getColorValue() != null && spec.getTextKey() != null;}

annotation expresses intent and makes

analysis – by human or tool - easier

Page 32: Java language-based security (in general and for mobile phones in particular)

32

Java metadata tags

• introduced in Java 1.5 (JSR 175)• JSR 305 "Annotations for Software Defect

Detection" currently in progress– @NonNull, @Nullable– @Tainted, @Untainted to find input

validation problems– @NonNegative– @WillClose, @WillNotClose– @CheckReturnValue

• enables static analysis / special typecheckers

Page 33: Java language-based security (in general and for mobile phones in particular)

33

Information flow policies

• Another category of security requirements:– information flow policies

• Eg– "untrusted input data should not be fed into

sensitive API calls"– "only numbers obtained from phonebook

should be used as 1st argument of sendSMS"

Page 34: Java language-based security (in general and for mobile phones in particular)

34

Information flow policies using Java tags

• Java tags can be used to enrich type information– eg @PhoneNr , @Tainted, @ Confidential,

@CreditCardNr

that can be used by compilers & typecheckerspublic class Connection {

public void sendSMS(@PhoneNr String number) {...}

}

public class Phonebook {

public @PhoneNr String getNumber(int offset) {...}

}

public class Connection {

public void sendSMS(@PhoneNr String number) {...}

}

public class Phonebook {

public @PhoneNr String getNumber(int offset) {...}

}

Page 35: Java language-based security (in general and for mobile phones in particular)

35

Information flow policies using Java tags

public class Input {

public @Tainted String read() {...};

}

public class System {

public void sensitiveAction(@Untainted String st) {..}

}

public class InputValidation{

public @Untainted String validate(@Tainted String st){..}

}

public class Input {

public @Tainted String read() {...};

}

public class System {

public void sensitiveAction(@Untainted String st) {..}

}

public class InputValidation{

public @Untainted String validate(@Tainted String st){..}

}

Checking input validation using tags for (un)tainted info• cf Pearl in tainting mode

Page 36: Java language-based security (in general and for mobile phones in particular)

36

• Tainting approach works for explicit information flow, but not for implicit flows, eg for(i = 0; i< password.length; i++){

for(c ='a'..'z') if (password[0]=c) print(c);

}

leaks password but does not have explicit flow

• JSR (Java Specification Request) 175 to define standard tags that can be used by variety of tools– also @NonNull : very basic JML specs can be expressed using Java tags

Page 37: Java language-based security (in general and for mobile phones in particular)

Questions?