Mobile Code Security

1
Mobile Code Security

• Yurii Kuzmin

2
What is Mobile Code?

• Term used to describe general-purpose executables
  that run in remote locations.
• Web browsers come with the ability to run
  general-purpose executables.
• The executable can be written by anyone and
  executed on any machine that runs a browser.
• Same code can be executed on any platform
  regardless of the operating system and hardware
  architecture.

3
History

• Concept is not new
• Several object-based systems are well established
  (CORBA)
• HotJava web browser itself written in Java,
  first browser to support applets.
• Version 2 of Netscape Navigator (spring of 1996)
• Version 3 of Internet Explorer (winter of 1995)

4
Security Concerns

• Global, homogeneous, general-purpose interpreter
• Interpreter is part of the browser
• Attacker can run native code on the executing
  machine
• Attacker can include malicious machine code in
  executables and cause it to be executed
• Code executed by a user runs with that users
  permissions

5
Security Techniques

• Sandbox Model
• Code Signing
• Hybrid Sandbox and Signatures
• Firewalling
• Proof-Carrying Code

6
Sandbox Model

• Contain mobile code in such a way that it cannot
  cause any damage to the executing environment
• Restrict access to a file
• Limit the ability to open network connection
• Java interpreter inside Internet browsers
• Each implementation of interpreter has a security
  policy
• Policy explicitly describes the restrictions

7
Sandbox Model

• Components of Java Interpreter
• Class loader
• Verifier
• Security manager

8
Class Loader

• Special Java object that converts remote bytecode
  into data structures representing Java classes
• The only way to add remote classes to machines
  local class is via the class loader
• Class loader creates a name space for downloaded
  code, local names are given priority, so remote
  classes cannot overwrite local names.

9
Verifier

• Performs static checking on the remote code
  before it is loaded
• Checks that the remote code
• Is valid virtual machine code
• Does not overflow or underflow the operand stack
• Does not user registers improperly
• Does not convert data types illegally

10
Security Manager

• Provides flexible access to potential dangerous
  system resources
• Security Manager classes represent a security
  policy for remote applets

11
Security Manager

• Public boolean AAA(Type arg1)
• SecurityManager security System.getSecurityMana
  ger()
• if (security ! null)
• security.checkAAA(arg1)
• Example is taken out of Mobile Code Security by
  Aviel D. Rubin

12
The Sandbox Model

• Error in any security component can lead to a
  violation of the security policy
• Risks are increased by the complexity of the
  interaction between components.
• If the class loader has incorrectly identified a
  class as local, the security manager might not be
  able to apply the right verifications

13
Code Signing

• The client manages a list of entities that it can
  trust.
• When a mobile executable is received, the client
  verifies that it was signed by an entity on the
  list
• If so, then it is run, most often with all of the
  users privileges
• Used by ActiveX

14
Code Signing

• Trusted code runs with full users privileges, or
  it doesnt run at all
• If an intruder can change the policy on a users
  machine, the intruder can then enable the
  acceptance of all ActiveX content.
• Legitimate ActiveX program can open the door for
  future illegitimate traffic

15
HybridSandbox and Signatures

• Attempts to merge benefits of the sandbox model
  with code signing
• Digitally signed applet is treated as trusted
  local code if the signature key is recognized as
  trusted by the client system that receives it
• Client downloads an applet and then consults a
  policy table for every signed applet
• Trusted applets can access file system, establish
  network connection and do other applications that
  are restricted by sandbox

16
Firewalling

• Selectively choosing whether run or not to run a
  program at the very point where it enters the
  client domain
• Web proxy or firewall can try to identify Java
  applets, examine them, and decide whether or not
  to serve them to the client
• Firewall approach assumes that applets can
  somehow be identified

17
Firewalling

• Finjan Software and Security 7 have products that
  attempt to identify applets and then examine them
  for security properties. Only safe applets are
  allowed to run
• Techniques that they use are confidential
• Halting problem there is no general-purpose
  algorithm that can determine the behavior of an
  arbitrary program.

18
Firewalling

• Digitivity Inc. uses another approach
• Java applets are divided into graphical actions
  and all other actions
• Graphical run on the client machine
• Other run on a sacrificial playground machine

19
Proxy
Browser
1. Request for Page
2.Request for Page
Change ltappletgt tags
4. Modified Page
3. Page
Load Graphics Server
WEB
5. Request for Applet
Playground
Change I/O
6. Applet
Load applet
8. I/O
7. Modified Applet
20
Firewalling

• The playground architecture trusts small graphics
  packages because its easy to analyze
• More dangerous and untrustworthy mobile code has
  no access to meaningful resources
• This approach requires bytecode modification and
  cannot be used in combination with the usual
  approach to code signing

21
Proof-Carrying Code

• Is an active area of research today
• Technique for statically checking code to make
  sure that it does not violate some safety policy
• Some programs can construct a proof that they do
  not contain any buffer overflows
• Proves safety properties of code

22
Conclusion

• Best approach is combination of security
  mechanisms
• No techniques can protect users from social
  engineering attacks
• User education is the only way to combat mobile
  code attacks that are based on social engineering

23
References

• Mobile Code Security, Aviel D. Rubin
• Formal Aspects of Mobile Code Security, Richard
  Drews Dean
• Mobile Code and Security, Gary McGraw, Edward
  W. Felten
• Securing Systems Against External Programs,
  Brant Hashii, Manoj Lal, Raju Pandey and Steven
  Samorodin