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