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

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

• Erik Poll
• Digital Security group
• Radboud University Nijmegen

2
mobile code

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

P
Q
Internet
Code extension
OS
Resources
3
Example browser plugin
Firefox
Internet
libraries
OS
Browser plugin
Resources
4
Example Java enabled mobile phones
midlet 1
midlet 2
midlet n
Internet
JVM
APIs
code download
Mobile phone
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?

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 control
• even in the presence of untrusted - buggy or
  malicious - code

7
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
package C
applet A
JRE (Java Runtime Environment)

VM
APIs
Security Manager
Class Loader
hardware (CPU peripherals)
8
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
package C
applet A
JRE (Java Runtime Environment)

VM
APIs
Security Manager
Class Loader
hardware (CPU peripherals)
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?

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...

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
  VU149457
• 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 VU388289
• Sun Microsystems Java GIF image processing
  buffer overflow
• ...

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...

13
Security flaw in code signing check (Magic Coat)

• JavaSofts 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?

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, ...

15
Spot the defect in java.lang.String
class should be final to prevent malicious
subclasses
fields should be not be public to prevent
unauthorised changes, ie. preserve integrity

• package java.lang
• public class String
• public char contents public int offset,
  len
• // idea String is contentoffset ...
  offsetlen
• String() contentsnull offset0 len0
• String(char a)
• contents a offset 0 len
  a.len
• String substring(int take)
• if (takelt0) throw new
  NegativeSizeException()
• String s new String()
  s.contentthis.content
• s.offset0 s.lenMath.min(take,s.len)
  return s
• int getLength() return len
• ...

fields should be final (for thread-safety)
array should be cloned to prevent representation
exposure which allows unauthorised changes
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 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, ...

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

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

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

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

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!

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?
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

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((5xy)/2) is very suspicious code
• midlet will send at most 3 SMS
• ...
• Can we make such policies precise?
• Can we enforce these policies statically?

25
Policy for SMS in JML specifications
public class Connection //_at_ static ghost int
smsCount 0 //_at_ ensures smsCount
\old(smsCount) 1 public void sendSMS(/_at_
non_null _at_/ String number,
/_at_ non_null _at_/ String message)
public class Example //_at_ ensures
APIClass.smsCount \old(APIClass.smsCount)2 pu
blic void oneSMS() connection.sendSMS("31612
345678, "Hello") connection.sendSMS("31612345
678, "Goodbye")
26
JavaVerified

• current practice
• for describing
• behaviour of
• midlets
• graph showing
• screens
• transitions
• between them
• conformance checked
• by testing

27
midlet navigation graph

• added
• sensitive API
• calls

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

29
Lighterweight mechanism than program
specification verificationthan JML

• Java tags

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
31
Spot the defect

• ...
• if (spec!null) f.add(spec)
• if(isComplete(spec)) prefs.add(spec)
• ....
• boolean isComplete(_at_NonNull Preference spec)
• return spec.getColorKey() ! null
• spec.getColorValue() ! null
• spec.getTextKey() ! null

annotation expresses intent and makes analysis
by human or tool - easier
32
Java metadata tags

• introduced in Java 1.5 (JSR 175)
• JSR 305 "Annotations for Software Defect
  Detection" currently in progress
• _at_NonNull, _at_Nullable
• _at_Tainted, _at_Untainted to find input validation
  problems
• _at_NonNegative
• _at_WillClose, _at_WillNotClose
• _at_CheckReturnValue
• enables static analysis / special typecheckers

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"

34
Information flow policies using Java tags

• Java tags can be used to enrich type information
• eg _at_PhoneNr , _at_Tainted, _at_ Confidential,
  _at_CreditCardNr
• that can be used by compilers typecheckers

public class Connection public void
sendSMS(_at_PhoneNr String number) ... public
class Phonebook public _at_PhoneNr String
getNumber(int offset) ...
35
Information flow policies using Java tags

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

public class Input public _at_Tainted String
read() ... public class System public
void sensitiveAction(_at_Untainted String st)
.. public class InputValidation public
_at_Untainted String validate(_at_Tainted String
st)..
36

• Tainting approach works for explicit information
  flow, but not for implicit flows, eg
• for(i 0 ilt password.length i)
• for(c 'a'..'z') if (password0c) 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 _at_NonNull
• very basic JML specs can be expressed using
  Java tags

37
Questions?