Program Monitoring
Ulfar Erlingsson  Microsoft Research

Execution Monitoring Fundamentals
  ...

  - inlined reference monitors
    (Anderson 72, Erlingsson Schneider 99)
    Execution monitor that forwards events to security
    policy-specific validity checks
      -- kernel supported (implemented in kernel interface)
      -- interpreter based (wrap around program)
      -- modified application (included in program)

    Validity check
      -- something triggered by RM on each event
      -- encodes the secuirty policy
      -- perform arbitrary computation to decide whether
	 to allow event or halt
      -- Security Kernel (RM + VC)

    IRM: use 3rd tpe of RM implementation
     - use security automato to specify security policy
     - policy specify both RM and validity check
     - permanently added to application

    IRM has access to program abstractions, capture all
    potentially security-relevent events, rewriter works
    on machine language programs

    Issues:
      - how to capture all relevent events?
      - prevent application subverting inserted RM
      - preserve application behavior

    Advantage:
      - can enforce policies on application abstraction
      - each application can have a distinct policy
      - mechanism is simple and efficient and travels

Monitoring machine code execution
  - software fault isolation
    -- traditional hardware protection
      - RM on top of hardware and below the program (including OS)
      - Hardware execution monitor that forwards events to 
	validity checks
	  MMU hardware is RM for memory accesses
	  Access subject to validity checks on page tables
	  Hardware instruction decoder disallows certain
	    operations in non-privileged mode
    -- Enforcing hardware policies in software (aka SFI)
      (Wahbe Lucco Adl-tabadabi 97)
	Security automata receives as input the currently executed
	insruction and current program state; need to synthesis 
	"instruction" event
        -- checks memory related and control flow related instruction
	-- x86 SASI, modified gcc assembly, worst experinet: 4x
 
  - buffer overflow and mitigations
    -- (underflow?)
    -- stack smashing
    -- exception handler hijack
    -- register hijacking
    -- local pointer subterfuge
    -- v-table hijacking
    -- SEH clobbering
    -- Multistage attacks
    -- Parameter pointer subterfuge

    VC++ .NET
    ---old------
    Previous function's stack frame
    Function argument
    Return address
    Frame pointer
    - Cookie = f(return address)   (Cowan et al, 98)
    EH frame
    Local variables and locally declared buffers
    Callee ssave registers
    Garbage
    ------------
    ----new-----
    Previous function's stack frame
    Function argument
    Return address
    Frame pointer
    - Cookie = f(return address)
    EH frame
    Locally declared buffers
    Local variables and 
    Callee ssave registers
    Garbage
    ------------

    Cookie: is the size of a pointer, has >20bit of randomness.
      -- compile with /GS

    Implementing NX
      - hardware support on many CPUs
      - breaks lots of software
      - can synthesize on IA-32 chips
    Circumventing NX (aka Jump-to-libc)
    Address-space Randomizatio [PaX]  
    Circumventing ASLR [Durden 02]
      - learn the memory layour specifics of your target
	for attack
      - use brute force [unpublished, Boneh et al 04]

Advanced IRMs & future work
  - low-level actions and event synthesis
  - static analysis, alternate remedies, etc
      better than EM: security via static analysis
      but hard to prove program properties, one way is
      to write program in a way that facilitates proving
      certain properties about it.
