Efficient Code Certification for Open Firmware

1
Efficient Code Certification for Open Firmware
OASIS PI Meeting, Santa Fe NM July 25, 2001

• Matt Stillerman, PhD
• Odyssey Research Associates
• 33 Thornwood Drive, Suite 500
• Ithaca, NY 14850
• matt_at_oracorp.com

2
Collaborators

• Dexter Kozen, Cornell University
• Thomas Merritt, CodeGen, Inc.

3
Problem Malicious Firmware

• Information systems are vulnerable when booting.
• Security measures are not started yet.
• Boot software runs in a very privileged mode it
  can do anything.
• This vulnerability would be exploited by
  inserting malicious code into the boot program
  (firmware).
• Odysseys Solution
• BootSafe will detect all non-TCB firmware
  programs with the potential to violate the
  security policy, at boot-time, before they run.

4
Why worry about boot firmware?

• The boot program
• tells the operating system about the hardware
  configuration. It could lie. (e.g. Here is an
  approved cryptographic device.)
• initializes all hardware devices. It could
  operate those devices maliciously, fail to
  initialize them, or damage them. (e.g. Its time
  to erase all keys.)
• loads the operating system. It could hack the
  OS, and thus is capable of disabling,
  circumventing, or subverting all trusted host
  software. (e.g. Substitute a spoof version of
  the login module for the real one.)

5
Practical, Exploitable Weakness

• Within the means of a nation-state or well-funded
  organization.
• Several routes for insertion of malicious code
• Firmware patches and upgrades
• Device drivers for peripheral devices
• Console boot prompt gives full access to an
  interpreter.
• User/Administrator community generally not aware
  of this danger systems are wide-open to
  arbitrary harm.

6
Expected Benefits of BootSafe

• Directly detects what users care about potential
  violations of the security policy.
• Malicious code is identified before it runs.
• Code is rechecked before each boot cycle.
• All trust resides in end-user systems. Can
  accept code updates from untrusted suppliers.
• End-user gains well-founded trust without source
  code.
• Complements code-signing integrity approaches.
• Based on a rigorous formal analysis, thus can
  achieve high assurance.

7
Scope Open Firmware

• BootSafe will detect malicious code in Open
  Firmware-based systems.
• Open Firmware is a widely used standard
  platform for boot firmware (IEEE-1275).
• Standardizes the execution environment, the
  device API, the operating system API, and the
  user interface.
• Popular because it enables reusability and
  portability of boot code.
• Used by Sun Microsystems, Apple, and many
  embedded system vendors.
• Used in DoD and US Government information systems.

8
Forth-based Solution
Open Firmware Boot Host
Software Developer
Other Software
Verifier
Fcode Interpreter
Forth Source program
certificate
Fcode programs
Certifying tokenizer
BootSafe
9
Java-based Solution
Java Program
javac
ROM Storage
certificate
J2F certifying compiler
JVM Bytecode
Fcode
Firmware Developer
10
Fcode Loading and Verification
Other Software
Verifier
Fcode Interpreter
certificate
Fcode programs
Loading
Fcode
Boot Program
ROM Storage
11
Advantages of Java

• Java is strongly typed.
• JAVA bytecode is strongly typed -- can carry
  typing down to Fcode type annotations that
  reflect JAVA typing
• Fcode verification mimics JAVA bytecode
  verification
• Open Firmware is naturally object-oriented
• The device tree has a natural object-oriented
  inheritance structure -- can provide templates
  with general functionality for each device type
  that can be subclassed
• Static/instance structure already present in Open
  Firmware

12
Advantages of Java

• Thus our security policy will be very naturally
  expressed in terms of Java, as
• Type checking.
• Safety of Java namespace. Non-malleable class
  definitions.
• Requirement to implement specific standard
  interfaces.
• Liberal use of final and private attributes.
• Restrictions on lexical references

13
First Level Policy Type Safety

• Memory safety
• Control flow
• Stack safety
• Compiling down from a type safe language ensures
  this.
• Enforced in Fcode by the analog of Java bytecode
  verification.

14
Second Level Policy Device Encapsulation

• Each physical device may only be accessed through
  its device driver using the published driver
  interface.
• Each device driver interface conforms to the
  standard.
• No additional public interface is defined.
• No external access to internal methods or data
  structures of the device driver.
• All calls to driver interface methods are
  well-formed.

15
Third Level Policies

• Threat categories they address
• Malicious inter-device access
• Resource exhaustion
• Incorrect device alias or name
• Malformed device tree
• Corruption of the operating system
• As it is loaded
• As it runs
• Wrong OS boot device.

16
Preventing Malicious Inter-device Access

• Allow only plausible forms of access, by device
  type.
• Enforce additional site-specific restrictions on
  inter-device access.
• Enforcement
• Check explicit calls in device driver code
  against policy.
• Restrict dynamic inter-device calls where the
  target or method is computed in a non-obvious
  way.
• Mediate calls by a run-time check. Verify that
  the correct enforcement code (boiler-plate) is in
  place.

17
Status

• Phase I SBIR, nearly completed
• Accomplishments
• Forth-based and Java-based approaches.
• Feasibility
• Architecture
• Draft security policy
• J2F program
• Potential
• Addresses a real vulnerability
• Commercially attractive

18
Eager Java Class Initialization
Eager class loading and initialization would be
preferable to Javas lazy class loading
policy. Problem What order to initialize classes
with cyclic class initializer dependencies. class
A static int a B.b 1 ...
2 class B static int b A.a 1 ...
1