Mobile Code Security

Mobile Code Security
- Dr Lawrie Brown
- School of Computer Science
- Australian Defence Force Academy
Introduction
- increased interest in "mobile code"
- from remote, "untrusted" systems
- executed on local system
- eg applets, dynamic email, TINA
- are serious security & safety issues
- will outline general approaches to, & specific examples of "safe" systems
Mobile Code
- have many names:
  - mobile agents, mobile code, remote code, downloadable code, active capsules
  - all deal with local exec of remote code
Mobile Code Examples
- Web Applets
  - written in Java
  - automatically loaded & run ex html
- Dynamic Email
  - Safe-TCL scripts included in email
- TINA Building Blocks
  - support for 3rd party services which can manipulate network resources
Low-level Security Issues
- access control
- user authentication
- audit
- data integrity
- non-repudiation: sender & receiver
- data confidentiality
Low-level Security Issues 2
- techniques for these well known
  - using cryptographic extensions to communications protocols
- OSI Security Framework
  - ISO 10181, X.810-X.816 standards
- IETF IP-SEC proposals
- Secure Web protocols
- need system to provide these
Mobile Code Safety
- concerned with safe execution of imported code on local system
- address threats due to rogue code
- types of attacks:
  - denial of service
  - disclosure of confidential information
  - damage or modification of data
  - annoyance attacks
Example Scenarios
- Video-on-Demand service which discretely scans local files for info
- On-line game which opens a covert connection to run programs locally
- Invisible program that captures system activity info
Resource Access & Safety
- running programs have access to system resources
  - traditionally to all user's resources
- "mobile code" must have restricted access to resources, BUT
- must allow some access in order to perform required functions
Resources Accessed
- file system
- network
- random memory
- output devices (display, speaker ...)
- input devices (keyboard, mic ...)
- process control
- user environment
- system calls
Language Support for Safety
- type safety
  - language designed with type safety
    - eg arrays stay in bounds, valid pointers
  - want assurance of type-system soundness and safety
  - want validation of type checking implementations
  - without compromising efficiency
Language Support for Safety
- modular programming
  - separate interfaces from implementations in programs
  - layering of libraries & module groups
  - particular care with interfaces at security boundaries
    - remove general routines which could compromise security
    - replace with more specific, safer ones
      - eg general file access -> write in tmp dir
Granting Access to Resources
- need a security policy:
  - fixed for all "mobile code" unit
    - restrictive but easy
  - negotiate each "mobile code" unit
    - harder, basis needed for negotiation
    - perhaps based on various profiles
  - user verifies access requests
    - relatively easy, can get annoying
- evaluation & certification criteria
Mobile Code Technologies
- Several approaches:
- Source Code
- Intermediate Code
- Platform-dependent Binary Code
- Just-in-time compilation
Source Code
- source for "mobile code" unit used
- executed by interpreter
  - provides a safe execution "sand-box"
  - responsible for vetting source
  - safety depends on its implementation
  - Advantages
    - relatively small code, easily contained
  - Disadvantages
    - slow, hard to expand functionality
Programmable MUDs
- some MUDs are programmable
  - eg MUCK, MOO, UberMUD
- source authored by arbitrary users
- executed in MUD interpreter
  - no other access to host system
  - full access (as user) to MUD DB
- users need explicit permission to author code
Safe-TCL
- TCL
  - simple, clean, interpreted, embeddable command language
  - with graphical toolkit (Tk)
- Safe-TCL
  - subset with restricted features
    - limited file sys access, can't exec cmds
  - executed by "untrusted interpreter"
  - extension code, invoked by any code, uses "trusted interpreter"
Dynamic Email with Safe-TCL
- Dynamic Email
  - concept of augmenting email to include active messages
    - using a portable, powerful mechanism
  - can exec code on delivery or access
  - one proposal uses Safe-TCL
    - uses application/safe-tcl and multipart/enabled-mail MIME types
    - with extra mail specific access routines
      - eg order custom teeshirt after filling in form
JavaScript
- source level scripting language, embedded in HTML (is NOT Java)
  - interpreted by web browser
  - allows control over web browser
  - has access to most web page content
  - full interaction with displayed content
  - can access Java methods (& vica versa)
  - very coarse security management
Intermediate Code
- programs compiled to platform independent intermediate code
- code executed by interpreter
  - faster to interprete than source
  - provides a safe execution "sand-box"
  - safety depends on its implementation
  - Advantages
    - small code, can vet code
  - Disadvantages
    - moderate speed
JAVA
- "executable content" technology
  - interpreted, dynamic, type-safe O-O lg
    - runtime bytecode verification
    - dynamic binding
    - automatic memory management
    - exception processing
  - security depends on:
    - verifier/interpreter AND
    - standard library implementation
      - esp SecurityManager
Telescript
- distributed application technology using "mobile agents"
  - are migrating processes
    - "mobile agents" can ask to "go" elsewhere
  - interpreted, dynamic, type-safe O-O lg
    - runtime type checking & dynamic binding
    - automatic memory management
    - exception processing
  - with object persistence & remote access
  - authentication & protection integral
Native Binary Code
- execute native binary code
  - gain maximum speed
  - but platform dependent
- safe execution requires
  - restricted use of instruction set
  - restricted address space access
- approaches
  - heavy address space protection
  - verified use of trusted compiler
Just-in-time Compilation
- combines portability with speed
  - from source (slower, easier to check)
  - from intermediate code (faster)
- utilise own trusted compiler
  - verify code, insert run-time checks
- eg
  - Java JIT compilers
  - Omniware
Omniware
- technology for "mobile code"
  - compile source (C++) to OmniVM
  - at run-time translated to native code
- relies on "software fault isolation"
  - to enforce safe execution of binaries
    - adds special checking code
    - emulates MMU in software
    - each module in own protection domain
  - run-time env vets access to resources
Theory vs Practise
- have some good proposals
- but have flaws in practise
- most recent effort focused on Java
- can draw some lessons from it
Java Implementation Flaws
- network security & DNS spoof
- buffer overflows in sprintf
  - mostly fixed, except in javap
- storage layout disclosure
- public proxy variables (HJ)
- inter-applet security
  - an applet can discover which other applets run & control all threads
Java Language vs Bytecodes
- superclass constructors
  - most dangerous attack thwarts typing
  - lg blocks but bytecode verifier allows partially initialised class loaders etc
  - gives access to object constructors
- illegal package names
  - leading / allows absolute pathnames to packages, trusted code since local
- object initialisation problematical
Security Failure Lessons
- experience with systems (esp Java) have highlighted some danger
- failures can occur in
  - implementation
  - specification
- correct specification does not prevent poor implementation
- need formal semantics & verification
Conclusions
- "mobile code" is here
- safety => controlled resource access
- approaches
  - source, intermediate code, binary, JIT
- secure systems need correct
  - specification AND
  - implementation
- much research & development yet
Questions

The paper associated with this seminar, entitled " Mobile Code Security - http://lpb.canb.auug.org.au/adfa/papers/mcode96.html", is available as Technical Report CS07/96, Aug 1996. It was also presented to AUUG96 in Melbourne, Sept 1996.

Lawrie.Brown@adfa.edu.au / 10-Jul-96