[25302] in bugtraq
Re: CORE-20020409: Multiple vulnerabilities in stack smashing
daemon@ATHENA.MIT.EDU (Mariusz Woloszyn)
Mon Apr 29 20:32:28 2002
Date: Sun, 28 Apr 2002 22:27:10 +0200 (EEST)
From: Mariusz Woloszyn <emsi@ipartners.pl>
To: =?iso-8859-1?Q?Iv=E1n_Arce?= <core.lists.bugtraq@core-sdi.com>
Cc: BUGTRAQ@securityfocus.com, <core.lists.vulnwatch@corest.com>
In-Reply-To: <254c01c1eb18$7af4f1a0$2e58a8c0@ffornicario>
Message-ID: <Pine.LNX.4.43.0204282207320.9613-100000@dzyngiel.ipartners.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-2
Content-Transfer-Encoding: 8BIT
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
