SystemsSec 2016W Lecture 14

Topics and Readings

• Aleph One (aka Elias Levy), Smashing The Stack For Fun And Profit (Phrack 49, 1996)
• Crispin Cowan et al., StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks (USENIX Security, 1998)
• Wikipedia, Buffer Overflow Protection

Notes

How to cause a buffer overflow?

• buffer overflows are usually done by taking advantage of protocols that come standard across systems
• memory mapping is one concept that is standardized across many systems, therefore, it can be guessed and predicted
• the similarities/standardization is based on machine instructions
• this can be changed using randomized instruction sets but it is not done on modern systems
• another regularity/standardization is memory layout but can be protected against using randomize memory layout (ASLR)
• another regularity is runnable code (executable memory), but can be protected by changing parts of memory to non-executable memory
• but changing parts of memory to non-exec code breaks the use of generating code on the fly
• StackGuard is a technique used to protect against buffer overflows
• the regularities/standardizations are the most modified part of memory to protect against overflows
• the cost of these things (armour the stack) causes process to be slow as more computations are required for security

Stackguard

• works by inserting a canary word; a special value on every function exit, that is checked at every function exit
• The compiler does not know it
• It must be generated at runtime
• Placed between Ret and local variables
• Idea is that if overflow occurs, the canary word will be overwritten and when the canary word is checked, it won't match and the process will blow up

ff
|-------------------|
|---Main + offs---| SP (main)
|---------------| canary word can be put here
|---------SP-------| all the registers*, SP -> FP
|-------------------|
|----Locals-----|
|---Ret Addr----|
|-----locals-------| address 20000
|-------------------|
|--code (text)--|
|--code (text)--|
|--code (text)--|
|--code (text)--|
0

• Hardware changing really fast is misleading in CS, but software lags behind
• ex is speech recognition and learning. The algorithms are old, but the HW thats finally caught up so these slow algos can be run faster
• there are many other defences against buffer overflow, but they are not really deployed (see wikipedia link)
• in hardware, there is an idea called control flow integrity (CFI) to detect an attack (waste of time according to anil), good way of protecting buffer overflows but maybe not protect against backdoors

Why do we still care about buffer overflows?

• legacy code still exists in the world, that is why we will care about buffer overflows.
• not all legacy code has or can be updated
• fixing legacy code can cause important parts of code to break
• buffer overflows usually occur because the protections are not enabled properly
• C is considered unsafe language, and because so much of code in the world is written in C/C++, these exploits can be used

Other Defence: watching program behaviour

• watching how program behaves, looking for security violation
• done by profiling code the program executes
• can lead to slowing the processes, this is fixed by not monitoring everything, just where things can go wrong.
• what to monitor?
  • sys calls
  • anomaly detection can be used to protect against backdoors
• problem is, either layout everything that is permissible (white list) or what is not allowed (blacklist)
  • White list do not account for how system might used
  • Black lists do not specify everything that can be disallowed
• even with stupid models, we can do a lot
• used to check privileged entities is different ways
• defences beat by acting normally but mixing in things you want to do (mimicry attack)
• a buffer overflows fit into this by having the attack run code that acts normally, not detected by anomaly detection
  • very hard to do when included with canary and randomizing