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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 27 Mar 2014 18:39:52 +0100 From: Robert Święcki <robert@...ecki.net> To: fulldisclosure@...lists.org Subject: Re: [FD] Adventure with Stack Smashing Protector (SSP) 2014-03-27 4:08 GMT+01:00 Adam Zabrocki <pi3@....com.pl>: > 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. > Hi Adam, Quite an interesting read! Thx for preparing it. So it seems to me that revealing the VM layout or SSP cookies is important when we're attacking application which is operating with different set of privileges or having access to different resources than the attacker has. IMO it boils down to 2 basic cases a). attacking a network/remote service b). attacking a local service which is operating with different set of privileges (a system service, a setuid binary) Some of the presented ideas require ability to read output from stdout/stderr, what limits the attack to set-uid binaries (or, to other esoteric & and not-likely cases, like 644 stdout/stderr log files etc). When set-uid application is executed libc is more "cautious" about printing debug data, or accepting env-vars (like LIBC_FATAL_STDERR_). So my point would be that some of those conditions required for successful exploitation seem mutually-exclusive, e.g. you can try to attack/crash an app with LIBC_FATAL_STDERR_, but it's ignored for set-uid apps, and I'm not sure I'm seeing any other attack vector on privileged apps, unless I'm missing sth. Just wondering about your thoughts on that. -- Robert Święcki _______________________________________________ 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