Re: Stack Shield: defending from
[EMAIL PROTECTED] wrote:
Perhaps I don't see your point. How is this more secure than StackGuard?
StackGuard protection system has an extremaly grave bug
with the terminator and null canaries. In certain circumstances (not rare) this bug
can be exploited
preventing StackGuard to detect stack corruption. I'm not
the autor of this exploit howewer, so I will not post it without
his autorization.
So to refine your claim, this means that you believe StackShield is more
secure than the terminator version of StackGuard. I see no way in which
it is more secure than the random version. We have a new release of the
StackGuard compiler that fully supports random canaries even for shared
libraries. Release is imminent, pending completion of the web site
documentation.
To be fair, once you fix StackShield's response to a detected stack
smash, I know of no way in which StackGuard is more secure than
StackShield. At that point it comes down to the practical issues I
mentioned.
Addressing the vulnerability of the terminator version: we hypothesized
that the terminator StackGuard defense could be exploited if you could
find a vulnerable buffer that lets you overflow the buffer multiple
times before the affected function returns. Here's a straw-man example
of vulnerable code:
foo() {
char mybuf[25];
do {
gets(mybuf);
} while (!ok(mybuf));
}
If you find code like this, then you can "laminate" a terminator canary
in place after perpetrating the overflow to change the return address in
the activation record. There are problems
with this, though:
* the string function (in this case, gets()) must use the low-order
symbol in the Terminator Canary as a termination symbol
* you have to get your allignment *exactly* right
* you have to find code of this form. It's not impossible, but it is
relatively rare.
I'd be very interested in posted examples of code of this form (or any
other form claimed to be vulnerable) found in production programs.
Presumably you can point to the vulnerable code without violating the
ownership on your friend's exploit?
Stack Shield provides a front end for GCC and G++ to
automatize the compilation. So you have just to each occourrence of "gcc" or "g++"
with "shieldgcc" or "shieldg++" respectively.Also in future versions a front end for
make will added.
You will find in practice that this is not sufficient to re-build large
volumes of SRPMs with your tool. You have to have a program that is
called "cc" and behaves exactly like "cc", or else some packages will
weasle their way around your protecting compiler.
Crispin
-
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
NEW: Protect Your Linux Host with StackGuard'd Programs :FREE
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Re: Stack Shield: defending from stack smashing attacks
On Tue, 31 Aug 1999, "CC" = Crispin Cowan wrote: + So, why would one use the approach of saving the return address on + another stack, instead of patching the stack itself, like StackGuard? + The only reason I can imagine, is that one does not want to change the + stack layout. The benefit of not changing the stack layout, is that + you can do the change outside of the compiler. CC Another major advantage is that gdb continues to work. The CC StackGuard method fails for all programs that introspect the stack, CC gdb being the major example. And presumably it would mean you could compile kernels with it, which also fails with StackGuard (for Linux, at least). Cheers, Chris. --- --- Hardware Compilation Group, Oxford University Computing Laboratory, Wolfson Building, Parks Road, Oxford, OX1 3QD, U.K. tel: +44 (1865) (2)73865 e-mail: [EMAIL PROTECTED] http://www.comlab.ox.ac.uk/oucl/users/chris.keane/
Re: Stack Shield: defending from
This would seem to protect against precisely the same class of attacks as StackGuard: those that use buffer overflows to corrupt the return address in an activation record. The response to attack is subtly differet: * StackGuard: assumes the program is hopelessly corrupted, syslog's the attack, and exits. This potentially converts a root exploit into a denial-of-service attack if the victim program is a persistent daemon, e.g. inetd or nfsd, which you can fix with a watch-dog that restarts needed daemons. * Stack Shield: patches the return address and carries on. If in fact the return address is the only thing the attacker changed, then Stack Shield offers the advantage of no DoS attack. However, this is rarely the case; the overflow has likely corrupted a lot of the program's state into some random state, and so it will exhibit random behavior, and probably crash. As I said in the post Stack Shield is in beta. Future versions will contain a comparsion between the RET in the main stack and the RET in the secondary stack. To avoid performance decay where this is not required this will be added as a command line option. Perhaps I don't see your point. How is this more secure than StackGuard? StackGuard protection system has an extremaly grave bug with the terminator and null canaries. In certain circumstances (not rare) this bug can be exploited preventing StackGuard to detect stack corruption. I'm not the autor of this exploit howewer, so I will not post it without his autorization. On some other not-quite-security issues: * Compatability: o Stack Shield has a fixed size buffer for the secondary stack. Deeply recursive programs will bust this buffer. As I stated in the TECNICAL file future relases of Stack Shield will allow the user to specify the buffer size. o Stack Shield does not yet appear to have done the work necessary to support PIC mode, so it is unlikely to work with shared libraries. To tell the truth currentely Stack Shield does not support it. o Stack Shield is an outboard post-processor. This would be a HUGE compatability advantage, except that it appears to be a post-processor for assembly source files. Thus, you still need to have source code for the program to be protected. You also have to extensively hack make files to insert Stack Shield in the middle of compiling each file. The path of .c - .o - executable becomes .c - .s - stack shield - .o - executable. From our experience re-building all of Red Hat Linux with StackGuard, you can trust me that this will become an issue :-) Stack Shield provides a front end for GCC and G++ to automatize the compilation. So you have just to each occourrence of "gcc" or "g++" with "shieldgcc" or "shieldg++" respectively.Also in future versions a front end for make will added. o In Stack Shield's advantage, Stack Shield will work with gdb, while StackGuard can only work with a specially hacked gdb that knows about the StackGuard activation record format. * Performance: Stack Shield does a copy to the secondary stack and an increment in the prolog, and a compare and decrement in the epilog. This is essentially similar to the workload imposed by StackGuard using the "Random Canary" defense, where we have an outboard table of 128 random numbers that are statically modulo-mapped to functions. StackGuard in "Terminator Canary" mode (where the "canary" word is -1 (EOF), CR, LF, and 0; the set of common string function terminators) is likely to be faster. As I said before terminator and null canaries can be exploited. Thanks, Crispin - Crispin Cowan, Research Assistant Professor of Computer Science, OGI NEW: Protect Your Linux Host with StackGuard'd Programs :FREE http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ Vendicator P.S. Excuse me for my long quoting and for my English.
Re: Stack Shield: defending from stack smashing attacks
[EMAIL PROTECTED] wrote: Stack Shield is a new tool that add protection form "stack smashing" attacks at compile time without changing a line of code. The home page is http://www.angelfire.com/sk/stackshield It is still in beta. The home page say "Stack Shield uses a more secure protection system than other tool like Immunix Stack Guard." The "detailed information" page says "under construction" but the TECHNICAL file that comes with the download explains that the defensive mechanism is to create a second stack especially for return addresses. Similar to StackGuard, Stack Shield hacks the prolog and epilog functions to implement the defense, but instead of the StackGuard mechanism of instrumenting the main stack, Stack Shield copies the return addresses to the secondary stack. Upon return, the hacked epilog compares the return address on the secondary stack to that on the main stack. If they match, the return proceeds normally, and if they don't match, Stack Shield patches the main stack with the (presumably safe) return address from the secondary stack. This would seem to protect against precisely the same class of attacks as StackGuard: those that use buffer overflows to corrupt the return address in an activation record. The response to attack is subtly differet: * StackGuard: assumes the program is hopelessly corrupted, syslog's the attack, and exits. This potentially converts a root exploit into a denial-of-service attack if the victim program is a persistent daemon, e.g. inetd or nfsd, which you can fix with a watch-dog that restarts needed daemons. * Stack Shield: patches the return address and carries on. If in fact the return address is the only thing the attacker changed, then Stack Shield offers the advantage of no DoS attack. However, this is rarely the case; the overflow has likely corrupted a lot of the program's state into some random state, and so it will exhibit random behavior, and probably crash. Perhaps I don't see your point. How is this more secure than StackGuard? On some other not-quite-security issues: * Compatability: o Stack Shield has a fixed size buffer for the secondary stack. Deeply recursive programs will bust this buffer. o Stack Shield does not yet appear to have done the work necessary to support PIC mode, so it is unlikely to work with shared libraries. o Stack Shield is an outboard post-processor. This would be a HUGE compatability advantage, except that it appears to be a post-processor for assembly source files. Thus, you still need to have source code for the program to be protected. You also have to extensively hack make files to insert Stack Shield in the middle of compiling each file. The path of .c - .o - executable becomes .c - .s - stack shield - .o - executable. From our experience re-building all of Red Hat Linux with StackGuard, you can trust me that this will become an issue :-) o In Stack Shield's advantage, Stack Shield will work with gdb, while StackGuard can only work with a specially hacked gdb that knows about the StackGuard activation record format. * Performance: Stack Shield does a copy to the secondary stack and an increment in the prolog, and a compare and decrement in the epilog. This is essentially similar to the workload imposed by StackGuard using the "Random Canary" defense, where we have an outboard table of 128 random numbers that are statically modulo-mapped to functions. StackGuard in "Terminator Canary" mode (where the "canary" word is -1 (EOF), CR, LF, and 0; the set of common string function terminators) is likely to be faster. Thanks, Crispin - Crispin Cowan, Research Assistant Professor of Computer Science, OGI NEW: Protect Your Linux Host with StackGuard'd Programs :FREE http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
