oss-security - Adventure with Stack Smashing Protector (SSP)

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Thu, 27 Mar 2014 04:08:10 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: oss-security@...ts.openwall.com
Subject: Adventure with Stack Smashing Protector (SSP)

Hi,

One weekend I decided to analyze Stack Smashing Protector (SSP) code. I believe some of the observations I've made might also be interesting to others. Because of that I've created a not so small write-up...
... which can be summarized (without necessary details) 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:
     a. Via corrupting memory region pointed by "__environ" variable. 
     b. Via setting "LIBC_FATAL_STDERR_" to the edge of valid addresses. 
     c. Via forcing "alloca()" to fail – e.g. stack exhaustion. 
     d. There is one more bug which I’m analyzing more comprehensively at point 4. It may 
        indirectly force SSP to crash. It exists in the 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: 
     a. Force SSP to open "/dev/tty" 
     b. Force SSP not to open "/dev/tty" and assign to the "fd" descriptor "STDERR_FILENO" value: 
 
#define STDERR_FILENO 2 /* Standard error output. */ 
 
    c. Crash SSP via 2b. scenario 
 
4. We can indirectly crash SSP via the unwinding algorithm (read-AV or we can be killed by 
   "gcc_unreachable" or "gcc_assert" function) – DWARF stack (state) machine: 
     a. Simulate FDE object was not found 
     b. 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: 
     a. Stack cookie information leak. 
     b. Any kind of information leak 
     c. File corruption.



The full paper can be found here:
http://site.pi3.com.pl/papers/ASSP.pdf

Or through the blog-post:
http://blog.pi3.com.pl/?p=485

I understand this paper is long (maybe too long) but ~70% of this paper is just gdb output which shows the described behavior. The rest of the paper (32 pages) mostly has source code listings so the real write-up is very short (comparing to the whole paper).



Best regards,
Adam


-- 
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.