8th November 2012 - Session 2: Architectural strategies and attack techniques

Started with some leftovers from last time..

Input Output (IO) used to be programmed meaning the CPU had to read and write data manually. Easy to protect. We now have un-mapped IO where the device itself is responsible for doing the copy to memory. Requires a block of memory and bypasses the paging system (and hence the security restrictions). Went from synchronous to asynchronous and the device will interrupt when complete. Pre-mapped IO using sand-boxing and fully mapped IO with a synchronized page table could be realized but is to complex to be implemented in current hardware (resource consuming slowing it down). Intel VT-d mentioned as example.

Plug and play with automatic adding and removing of hardware, dynamically changing of configuration, loading of device drivers. In the old days OS'es had to be recompiled. Most of modern OS'es bulk volume is due to support of all possible devices. Signed but trusted? executable code running in ring 0 in contemporary operating systems.. USB devices can identify themselves as many types. Usually these changes does not need administration permission.

Access control architecture
Subjects access to objects granted or denied by the reference monitor. Distinction between identification and authentication of subjects. A subject can sometimes act as an object.

Information access control can be machine oriented like Linux read, write and execute permissions. Often simple and easy to verify correctness of but hard to use, or more man oriented, abstracted with greater granularity but because of it's complexity more difficult to prove "secure".
Access matrix model and Access Control Lists (ACL) were discussed.

Two types of access control policies were defined: Discretionary and Mandatory access control. In discretionary the user is allowed to change the security settings of objects. Windows and Linux usually has this configuration out of the box. Mandatory is simply a term used to describe a situation where an administrator decides on behalf of users what is allowed and thus restricting the user. Examples are adding SELinux or adding a Windows machine to a domain controller with stricter security policies.

Anderson report: The access control must be

1. Isolation: Tamper proof/resistant
   
2. Complete: Always evoked, all access checked
   
3. Verifiable: Must be small enough to be tested (mathematically sound)
   

Continue..

Architectural strategies

A system without requirements can't be insecure..

Neumann (2004)

• Sound architecture
  
• Minimize trust in components
  
• Never reach above or below the neighboring abstraction levels
  
• Use encapsulation
  
• Write modular
  
• Use a layered protection
  
• Constrain dependencies
  
• (Object oriented)
  
• Separate policy from mechanism
  
• Separation of duties, roles and domains
  
• Sound authentication
  
• Administratively easy access control lists (intuitive)
  
• Comprehensive accountability (logs)
  

Can programs be proven secure? Safety (they work), they terminate, and assumptions understood. Critical operations have used several programs written by different groups, and have the programs (running on different hardware) voting for the correct solution.

We got presented 3 strategies:

• virtual machines: abstraction of hardware for sharing
  
• emulation: emulating environments
  
• clean slate: scrap everything and start over (the academic way)
  

Attack techniques

• Denial of Service: Resource exhaustion by different means
  
• Privilege escalation (including impersonating)
  

Vulnerabilities

• (broken) Environmental assumptions
  
• Configuration flaws
  
• Implementation flaws
  

Threats

• Physical: Access to hardware
  
• Local: Access to terminal, logged in
  
• Remote: Access from the outside with no requirements
  

Exploits

1. Buffer overflows (buffer overruns) (A good explanation of stack attacks)
   
   • Protection is applied to pages, not variables
     
   • None executable stack/heap
     
   • Randomization of system code
     
   • Point guard (XP sp2: heap protection, Win7: fault tolerent heap)
     
   • See the video on Return to libc attack
     
   • And this for heap attacks
     
   
   
2. Cross Site Scripting (CSS): leakage between websites, in browser or via server
   
3. Unicode problems: Domain related like IDNA, bad character testing in folder traversal
   
4. Links: Hard and soft links that can give access to files not intended
   
5. Race conditions: Kernel lock of Linux, multicore introduces lots of old malware to crash, TOCTOU
   

Tutorial (Friday)

A repetition on IDNA, buffer overflows, root kits, usage of LaTeX, and a few more words on writing the term paper.

Resources for the term paper
at hig.no/biblioteket we got access to a lot of publications in addition to the physical books and magazines. To get access you can either search from within the schools network or access it via a proxy. The address for connecting is hig.proxy.no at port 1080. The next time you try to access a page you will be asked for your student/(employee) ID + your password. Since all communication will go through the proxy, it might be a good idea to disable it when done searching. The main reason for using these services is that often a lot of published papers are behind pay walls, and using Google or any other search engine to find them might not succeed. In addition, using URL's on internet as source is bad practice.

This is an example from IEEE Xplore when proxy is working like it should

Recommended sites

• Link Springer
  
• ACM digital library
  
• EEE Xplore
  
• ScienceDirect
  
• ISI Web of knowledge
  
• The DBLP Computer Science Bibliography