Adventure with Stack Smashing Protector (SSP)

[Nytro]

[h=1]Adventure with Stack Smashing Protector (SSP)[/h]

by pi3

Introduction.

I was heavily playing with Stack Smashing Protector a few years ago. Some of my research (observation) I decided to publish on phrack magazine but not everything. Two years ago my professional life moved to the Windows environment and unfortunately I didn’t have time to play with UNIX world as much as before. One weekend I decided to reanalyze SSP code again and this write-up is describing a few of my observations I’ve made during the work…

… which can be shortly summarized as:

Not security related…

1. We can change program’s name (from SSP perspective) via overwriting memory region where pointer to “argv[0]” points to.
   
2. We can crash Stack Smashing Protector code in many ways:
   
   1. 
      
   2. Via corrupting memory region pointed by “__environ” variable.
      
   3. Via setting “LIBC_FATAL_STDERR_” to the edge of valid addresses.
      
   4. Via forcing “alloca()” to fail – e.g. stack exhaustion.
      
   5. There is one more bug which I’m analyzing more comprehensively at point 4. It may indirectly force SSP to crash. It exists in DWARF stack (state) machine which is responsible for gathering information about the stack trace (“__backtrace()”) and prints it.
      
      
   6. We can slightly control SSP’s execution flow. (Un)Fortunately it doesn’t have any influence for the main execution (what about security?). Following scenarios are possible:
      
      1. Force SSP to open “/dev/tty”
         
      2. Force SSP not to open “/dev/tty” and assign to the “fd” descriptor “STDERR_FILENO” value:
         

#define STDERR_FILENO 2 /* Standard error output. */

1. Crash SSP via 2b. scenario
   

1. We can crash indirectly SSP via unwinding algorithm (read-AV or we can be killed by “gcc_unreachable” or “gcc_assert” function) – DWARF stack (state) machine:
   
   
   1. 
      
      
      

Somehow security related…

1. We can force SSP to allocate a lot of memory and cause Denial of Service via Resource Exhaustion attack.
   
2. Theoretical Information leak:
   
   
   1. 
      
      
      Full write-up is available

here
Best regards,
Adam ‘pi3? Zabrocki
Sursa: Adventure with Stack Smashing Protector (SSP) : pi3 blogStack cookie information leak.
Any kind of information leak
File corruption.
Simulate FDE object was not found
Simulate FDE object was found.