full-disclosure - [FD] Adventure with Stack Smashing Protector (SSP)

Open Source and information security mailing list archives

Message-ID: <20140327030859.GB8971@pi3.com.pl>
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/

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