lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Mar 2014 04:08:59 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: fulldisclosure@...lists.org
Subject: [FD] 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

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists