Bugtraq mailing list archives

Re: CORE-20020409: Multiple vulnerabilities in stack smashing protection technologies


From: Mariusz Woloszyn <emsi () ipartners pl>
Date: Sun, 28 Apr 2002 22:27:10 +0200 (EEST)

On Tue, 23 Apr 2002, [iso-8859-1] Iván Arce wrote:

1) Control of function's arguments

In [8] and [9] a method to exploit stack based buffer overflows on stack
protected
programs is presented. In the example, a local pointer is used to write to
arbitrary
memory locations within the program's memory space. This technique can be
extended
to exploit the fact that in standard C compiled programs, function arguments
are located
in the stack at "higher" addresses than the return address:


Above technique (extended) WAS described in [8]
(http://www.phrack.org/show.php?p=56&a=5):

"In this example we have our pointer (dst) on the stack beyond the canary
and RET value, so we cannot change it without killing the canary and
without being caught...

Or can we?

Both StackGuard and StackShield check whether RET was altered before the
function returns to its caller (this done at the very end of function).
In most cases we have enough time here to do something to take control of
a vulnerable program.

We can do it by overwriting the GOT entry of the next library function
called.

We don't have to worry about the order of local variables and since we
don't care if canary is alive or not, we can play!"


2) Returning with an altered frame pointer

It WAS described in [8] also:
"StackShield protection can be bypassed by overwriting the saved %ebp
which is not protected. One way of exploiting it (under the worst
conditions) was described in >>The Frame Pointer Overwrite<< by klog in
Phrack 55 [4]."

"[4] klog. The Frame Pointer Overwrite
     http://www.phrack.com/search.phtml?view&article=p55-8";


4) Pointing the caller's frame to the Global Offset Table (GOT)

VERY interestin aproach! :)


All I wanted to say is that most of above was described (clearly? ;) in
the fall of 1999 and published in May 2000.

Anyway: THX for credits.

--
Mariusz Wołoszyn
Internet Security Specialist, Internet Partners


Current thread: