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
Internet
Q
Code extension
OS
Resources
2
Example: browser plugin
Firefox
libraries
Internet
Browser plugin
OS
Resources
3
Example: Java enabled mobile phones
midlet midlet
1
2
midlet
n
Internet
code download
JVM
APIs
Mobile phone
4
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?
5
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 control
even in the presence of untrusted - buggy or
malicious - code
6
Java language guarantees – part I
• applet A can only access visible methods & fields
• eg not to private fields
• no pointer arithmetic to access memory "illegally"
applet B
applet A
JRE
(Java
Runtime
Environment)
VM
APIs
Security
Manager
package C
Class
Loader
hardware (CPU + peripherals)
7
Java language guarantees – part II
• 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
applet B
applet A
JRE
(Java
Runtime
Environment)
VM
APIs
Security
Manager
package C
Class
Loader
hardware (CPU + peripherals)
8
• 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?
9
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...
10
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
...
11
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...
12
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?
13
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, ...
14
class should be
final to prevent
fields should be not be
malicious
public to prevent
Spot the defect in java.lang.String
subclasses
unauthorised changes,
ie. preserve integrity
package java.lang
public class String{
public char[] contents; public int offset, len;
// idea: String is content[offset ... offset+len]
fields should be final
String() {contents=null; offset=0; len=0;}
(for thread-safety)
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;
}
array should be cloned to
int getLength() { return len; }
prevent representation
...
exposure which allows
unauthorised changes
15
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 correct
a particular Java applet may still be vulnerable to attacks by
untrusted code
Programming guidelines have been proposed to rule out known
vulnerabilities
• eg no public fields, ...
16
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
17
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
18
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
19
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
20
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!
21
MIDP security bugs
• Phenoelit attack midlet on Siemens SS55 phone
– creates race condition
to let user unwittingly
authorise SMS
text message
OKDo
to you
sendwant to
SMS to
6492?
play
game?
22
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
23
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?
24
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 Example {
//@ ensures APIClass.smsCount == \old(APIClass.smsCount)+2;
public void oneSMS() {
connection.sendSMS("+31612345678, "Hello");
connection.sendSMS("+31612345678, "Goodbye");
}}
25
JavaVerified
current practice
for describing
behaviour of
midlets:
graph showing
screens &
transitions
between them
conformance checked
by testing
26
midlet navigation graph
added:
sensitive API
calls
27
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
28
Lighterweight mechanism than
program specification & verification
than JML:
Java tags
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
30
Spot the defect
{ ...
if (spec!=null) f.add(spec);
if(isComplete(spec)) prefs.add(spec);
....}
annotation expresses
intent and makes
analysis – by human or
tool - easier
boolean isComplete(@NonNull Preference spec){
return spec.getColorKey() != null
&& spec.getColorValue() != null
&& spec.getTextKey() != null;
}
31
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
32
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"
33
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 & typecheckers
public class Connection {
public void sendSMS(@PhoneNr String number) {...}
}
public class Phonebook {
public @PhoneNr String getNumber(int offset) {...}
}
34
Information flow policies using Java tags
Checking input validation using tags for (un)tainted info
• cf Pearl in tainting mode
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){..}
}
35
• 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
36
Questions?