Execution Time Security: Multiprocessors and MAC

1
Execution Time SecurityMultiprocessors and MAC

• Paul Williams

This briefing is provided for information only.
The opinions expressed within are those of the
author and do not necessarily reflect the views
of CERIAS, the US Air Force, or the US Government
2

• Our information systems are vulnerable
• Detecting attempts to exploit both known and
  unknown vulnerabilities is difficult!
• The detection system is itself a target

3
Introduction

• Background
• Thesis Statement
• Lit Review
• Research Goals
• IDS Protection
• CoPIDS
• CoPIDS Shadows
• Detecting Overflows
• Research Tasks
• General Thoughts

4
Research Hypothesis
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Coprocessor-based Intrusion Detection/Intrusion
  Prevention Systems (CoPIDS) can be more effective
  than Standard Uniprocessor-based IDS (StUPIDS)
• CoPIDS running on a separate processor is less
  vulnerable to attack
• Running concurrently with attack code affords
  CoPIDS more opportunities to detect and respond
  to attacks
• Running in parallel affords CoPIDS the ability to
  monitor instruction flows, memory accesses, and
  I/O operations, and control the operation of
  production processors
• The CoPIDS can do more security related work than
  can a StUPIDS with same workload

5
1. Less Vulnerable
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Keeping the IDS running during attacks on the
  production processes is a primary goal of this
  research.
• Reducing vulnerability requires reducing ways
  attacks can change the state of the IDS
• Scheduler, critical kernel data structures, IDS
  data structures, etc.
• Resources used to report attack or to respond
• The IDS must be given an opportunity to validate
  attempts to access or modify its state

6
1. Less Vulnerable
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Architecture must ensure IDS processes have
  exclusive access to a processor
• Vital components used by the IDS may be
  physically or logically separate from components
  accessible by production processors
• This research focuses on the use of MAC
  protections available in some modern operating
  systems
• This type of protection is the main reason MAC is
  built into operating systems like Trusted BSD and
  Solaris
• My interests in this area are just extensions to
  this basic idea

7
2. Concurrency
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• In uniprocessor systems only one stream of code
  is active
• Attack code runs in isolation
• It may be able to compromise the system before
  any software countermeasures can operate
• This problem also exists in multiprocessor
  systems if a processor isnt exclusively
  allocated to the IDS
• Ensuring the IDS is always running removes this
  advantage from the attacker

8
3. Parallel
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• In SMP systems processors share architectural
  components like address, memory, and processor
  control busses
• CoPIDS can monitor the activity of protected
  processors
• CoPIDS can modify the code streams for the
  production processors
• In architectures with a master processor running
  the IDS on the master allows it to halt and
  resume the execution of the slaves while denying
  the slaves that ability

9
4. Relative Workloads
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• In a StUPIDS the amount of work done by the IDS
  often increases proportionally with the amount of
  work done by production processes
• This leads to a cutoff point after which one or
  the other type of activity must be curtailed
• In the case where security is paramount the
  slowdown of production processes is often
  unacceptable to users
• In the case where security processes are
  curtailed, malicious activity may not be detected
  in a timely fashion or at all
• By running IDS processes on a separate processor
  this cutoff point is raised significantly.

10
Literature Review
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Intrusion Detection
• TCBA
• Reference Monitors
• Coprocessor-based ID
• Virtual Machine-based ID
• Trusted Operating Systems

11
Intrusion Detection
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Lots of interesting stuff here, most not relevant
  to this presentation
• Typically IDS are discussed in terms of
• Host versus Network
• Anomaly versus Signature
• Current thinking adds Specification-based ID in
  the latter axis
• Knowledge about what the system is allowed to do
  makes it easier to detect deviations from normal
  behavior

12
Intrusion Detection
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Spafford et. al. describe several desirable
  characteristics of an IDS
• IDS must be fault tolerant
• Must be able to resist subversion
• Must not impose unreasonable overhead
• Must be configurable to match security policy
• Must provide graceful degradation

13
Intrusion Detection
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Many challenges facing IDS developers and
  researchers
• High error rates (Type I and II)
• Addressing via specification-based security
• Attacks on IDS
• Protective isolation of IDS state and algorithm
  implementation
• Integration of IDS with MAC reference validation
  mechanisms

14
TCBA
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Key idea is trust
• Cryptographic algorithms run on physically
  hardened coprocessors
• Older systems focus on secure bootstrapping
• New work centers on intellectual property rights
• Pros
• Implementations can support my work
• Cons
• Not focused on same aspect of security
• Crypto processors have narrow interface to rest
  of system

15
Reference Monitors
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Andersons 1972 study of AF security needs
  outlined these requirements
• Systems designed from the beginning to be secure
• Authorization mechanisms
• Access control mechanisms
• Control over all program and O/S execution

16
Reference Monitors
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Hypothesized that systems can be secured by
  reference monitor
• Monitors all references by users to programs or
  data
• Validates references against access control
  matrix
• Mediates each access
• The reference validation mechanism must
• Be tamperproof
• Always be involved
• Be small enough to formally test and validate

17
Coprocessor ID
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Research uses TCBA style crypto coprocessors to
  perform IDS tasks
• Advantages include
• Independence from host O/S
• Narrow interface is easier to protect
• Secure and verifiable boot process
• Trusted observercomms from IDS can be fully
  trusted
• Disadvantages include that narrow window into
  host O/S
• lack of interposition with IDS and host ops like
  system calls and kernel operations
• From Zhang et. al. idea of monitoring changes to
  O/S invariants

18
Virtual Machine ID
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Garfinkel et. al. protect IDS by pulling it out
  into a virtual machine monitor
• Largely isolates IDS from code running in VM host
• Approach has much in common with TCBA,
  Coprocessor, and reference monitor work
• Pros include visibility into hardware and events
  on the software/hardware interface
• Cons include need to extrapolate software state
  in VM host
• Only has visibility into hardware state

19
Trusted O/S work

• Way too much to discuss here, but some key goals
  are applicable (from LOCK)
• Minimize security impact on users
• Maintain performance with hardware
• Enemy inside the system
• Enhance security features
• MAC, DAC, RBAC, ACLs, MLS, etc.
• Least privilege

Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts
20
TrustedBSD MAC
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Developed by Network Associates Labs and the
  TrustedBSD Project
• Project goals include
• Permitting dynamic extension of kernel access
  control policy
• Separation of access control logic and policy
  from kernel services
• Permitting multiple policies to be loaded
  simultaneously with some useful notion of
  composition
• Provide support for common policy infrastructure
  requirements, thus reducing redundant efforts
• Support for multiprocessor system, including
  tight integration with kernel locking and
  threading mechanisms

21
TrustedBSD MAC

• Extensible and modular kernel access control
  framework
• Policy independent and agnostic
• Support for multiple labels in kernel object
• Persistent storage for file system labels
• Predictable composition of multiple policies
• Set of entry points to intercept operations on
  labeled object
• A variety of policies exist including Biba, MLS,
  RBAC, TE, etc.
• Models base decisions on factors like user
  identity, role, security clearance, as well as
  security labels on system objects

Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts
22
TrustedBSD MAC Policies

• Biba
• Fixed integrity levels protect high integrity
  level subjects and objects from modification by
  lower level subjects
• Used to protect the TCB in trusted O/S
• LOMAC
• Also uses integrity levels to protect high
  integrity level subjects and objects from
  modification by lower level subjects
• Allows high level subject to read low level
  objects, but then downgrades the subject to the
  lower level
• MLS
• The logical conjugate of Biba provides data
  secrecy
• Used in multi-level security environments

Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts
23
TrustedBSD Labeling
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Common labeling infrastructure
• File system, Processes, IPC, Network stack
  elements, Network interfaces, Devices, Kernel
  module management, Syscalls, Swap space
  management, Time management, NFS, Sysctl, etc.

24
TrustedBSD
Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts

• Interaction between policies, the MAC framework,
  and the system

25
TrustedBSD Entry Points

• Entry point invocations are compiled into kernel
  subsystems
• Several classes of entry points exist
• Label management
• Event notification
• Decision functions
• Access control checks
• Entry points accept contextual information
• Subject credentials, Object label pointers, Call
  specific arguments
• Exist in
• File system, Processes, IPC, Network stack
  elements, Network interfaces, Devices, Kernel
  module management, Syscalls, Swap space
  management, Time management, NFS, Sysctl, etc.

Background Thesis Statement Lit
Review Research Goals Research Tasks Thoughts
26
Research Goals
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Demonstrate solution to threats against the IDS
• Satisfies challenge mentioned earlier as well as
  thesis statement 1.
• Use a combination of integrity and multi-level
  security policies to protect critical IDS data
  structures and resources
• Demonstrate how a coprocessor can be used to
  defend against buffer overflow attacks
• Context is a worst case attack on MAC
  implementation

27
IDS Protection
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Goal Protect IDS in the event of a root level
  compromise
• IDS continues to operate
• The compromised process should not be able to
  change IDS state
• IDS should retain ability to raise alarm or
  respond to attack in meaningful manner
• IDS will hopefully detect attack
• Difficult problem in general case (no promises
  here!)
• Imperative that IDS detect attempts against
  itself or its MAC protection

28
IDS Protection
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Initial thoughts use LOMAC integrity protection
• IDS kernel data structures and algorithms are
  kept distinct those used by production processes
• Process structures, scheduling queues, scheduling
  code, etc.
• Lomac levels are assigned to system components as
  follows
• IDS gt Production Kernel gt User
• System components not needed by currently running
  processes have lowest possible integrity

29
IDS Protection
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Compromised process with highest production
  integrity level may not affect IDS state and
  operation
• If attacker makes use of low integrity resource
  the compromised process integrity level drops to
  low levelit can no longer effect state of the
  system

30
IDS Protection
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Need for additional protective measures for IDS
  assumes MAC in O/S is not sufficient protection
• Reasonable to assume MAC subsystem is vulnerable
• E.g. buffer overflow in privileged code
• Attacker has ability to run any code at all
  including privileged instructions and can
  directly access any part of system
• May not go through MAC entry points
• Can target MAC subsystemattempt to change data
  or short circuit mediation mechanism

31
CoPIDS
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Coprocessor has ability to
• Monitor instruction stream in production
  processors
• Set tripwire on specific instructions
• Turn on branch logging/reporting
• Track location of production process in code
  stream based on branches
• Modify code stream for production processors
• E.g. Intel docs state that even in-flight
  instructions can be modified (there are
  complications)
• Intercept specific interrupts
• Debug exceptions and GP faults
• Read only page modifications, etc.

32
CoPIDS
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Coprocessor has ability to
• Stop and restart production processors
• Via insertion of halt instructions or directly
  via inter-processor interrupts
• Detect accesses to memory locations
• Reads and writes to particular locations or I/O
  ports
• Execution of instructions at a particular address
• Monitors can be system-wide or process specific

33
CoPIDS
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Other resources may be available to IDS
• Security policy specification information
• syscalls, programs, times, roles, etc.
• Information from the compiler
• Branches from point x can only go to offsets
  a,b,c.
• Buffer sizes and locations
• Help from the compiler
• Region variables on buffers that invoke
  coprocessor monitoring tasks
• Canaries on critical memory locations

34
CoPIDS Shadows
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• The IDS can create shadow processes for certain
  key processes such as server daemons
• The shadow tasks switch when production tasks
  switch
• They monitor executing code for deviations from
  expected behavior
• Trace code streams all the time, or just in
  critical areas
• Periodically verify that key invariants hold
• Intercept and validate inputs

35
CoPIDS Shadows
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• They may be able to learn and remember normal
  behavior
• Which branches are normally taken in certain code
  regions
• System resource usage
• Which of the allowed syscalls are actually used
  in normal operation and what normal parameters
  look like
• If they encounter something which requires more
  cycles than the IDS processor can provide, they
  may be able to halt the production processor or
  temporarily co-opt it for IDS tasks

36
Detecting Overflows
Background Research Goals IDS Protection
CoPIDS Shadows Overflows Research
Tasks Thoughts

• Direct detection of overflow via canary
• Coprocessor sets debug register on RIP or old
  stack pointer
• An overflow will trip alarm
• Detection of program flow change
• Use of branch records in vulnerable region to
  determine if flow matches known behavior
• Detection of specification/policy violation
• Attempts to use prohibited resources such as
  system calls or other programs
• May include parameter matching on syscalls

37
Research Tasks
Background Research Goals Research Tasks Thoughts

• Modify FreeBSD kernel
• Implement hard processor affinity
• Create separate scheduling context for IDS
  processes
• Verify expected hardware functionality (Intel
  docs unclear)
• Will debug register on IDS processor detect write
  to watched location on production processor
• Determine method of intercepting messages on
  system bus
• Modify attack suite from Linux to FreeBSD
• Maybe use Linux compatibility mode
• Maybe use different shell code

38
Research Tasks
Background Research Goals Research Tasks Thoughts

• Prepare experimental subject daemons
• Simulate / hand create specification information
  (syscalls, parameters, allowed exec progs, region
  vars on buffers, etc.)
• Manually insert region variables if needed
• Apply LOMAC protection to system
• IDS gt Kernel gt User gt Unused

39
Research Tasks
Background Research Goals Research Tasks Thoughts

• Experiment
• Demonstrate that IDS can detect buffer overflows
• Demonstrate that IDS can use specification and
  history information to detect changes caused by
  attacks such as buffer overflows
• Demonstrate that compromise of process with root
  privileges cannot affect IDS through killing its
  processes or affecting its data files, etc.

40
General Thoughts
Background Research Goals Research Tasks Thoughts

• In order for this research to be meaningful I
  need to demonstrate that a CoPIDS can do some IDS
  tasks at least as well as existing or proposed
  solutions
• What do they monitor?
• Can I do the same with lower overhead/fewer
  resources/fewer changes, etc.?

41
General Thoughts
Background Research Goals Research Tasks Thoughts

• Carving out (somewhat) new niche in IDS domain
• (Early) Network-based ID tries to validate inputs
  before they reach the program
• (Late) Host-based ID uses logged information to
  determine if inputs caused deviations from policy
  (this is a stretch)
• (Execution time) This research uses specification
  information and the ability to monitor runtime
  behavior as it occurs to detect attacks when they
  happen. It also focuses on ensuring the IDS is
  difficult to compromise, and will therefore be
  able to respond appropriately even when the
  system has been compromised.

42
Questions?
43
NORAD

• North American Aerospace Defense Command