27

Mar

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. Via corrupting memory region pointed by “__environ” variable.
    2. Via setting “LIBC_FATAL_STDERR_” to the edge of valid addresses.
    3. Via forcing “alloca()” to fail – e.g. stack exhaustion.
    4. 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.
  3. 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. Simulate FDE object was not found
    2. Simulate FDE object was found.

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. Stack cookie information leak.
    2. Any kind of information leak
    3. File corruption.

Full write-up is available here 🙂
 
 
Best regards,
Adam ‘pi3’ Zabrocki

Filed Under O wszystkim i o niczym 

Comments

Leave a Reply




CAPTCHA * Time limit is exhausted. Please reload the CAPTCHA.