Date: Wed, 8 Dec 1999 15:30:27 -0800 From: Tani Hosokawa <unknown@riverstyx.net> To: Roelof Osinga <roelof@nisser.com> Cc: Alfred Perlstein <bright@wintelcom.net>, Jonathon McKitrick <jcm@dogma.freebsd-uk.eu.org>, Kris Kennaway <kris@hub.freebsd.org>, freebsd-chat <chat@FreeBSD.ORG> Subject: Re: Yahoo hacked last night Message-ID: <19991208153027.G1362@riverstyx.net> In-Reply-To: <384ED9C2.348253DC@nisser.com>; from Roelof Osinga on Wed, Dec 08, 1999 at 11:20:50PM %2B0100 References: <Pine.BSF.4.21.9912081154210.4557-100000@fw.wintelcom.net> <384ED9C2.348253DC@nisser.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 08, 1999 at 11:20:50PM +0100, Roelof Osinga wrote: > Alfred Perlstein wrote:
> >
> > For a function to be able to return to its caller it must store the
> > return address on the stack, what a buffer overflow generally does
> > is overwrite that return address with a pointer to some more data
> > on the stack which is actually machine instructions to exec a shell.
>
> How? Wouldn't it be a tremendous happenstance if the buffer that
> overflows actually just happens to be where the stack is? If you
> overflow a buffer you write bytes into dataspace where, in a
> protected environment, it won't get executed. No matter what you
> push onto the return stack. Worse, the i386 has several exceptions
> it can raise to signal stack over- and underflows so the stack could
> be a fairly well controlled environment. Actually, the same can be
> done for data space segments as well. Thereby preventing buffer
> overflows from overflowing into code space.
But none of this has to do with stack over/underflows. This is a buffer
overwriting part of the stack, which then returns to somewhere in your
code. As long as your stack segment overlaps with your data segment, it's
possible.
Remember that the stack grows downwards. Imagine:
addy description
ff00 stack (we're way into the stack!)
e000 stack
d000 stack
1000 data (buffer_a) (here's our data!)
0000 data
so, we have some kind of stuff. we've found a function in the program
that is doing a strcpy (naughty!) into buffer_a. we, the evil hacker,
have control over this buffer because nobody's doing bounds checking.
we feed it d000-1000-code_len bytes of 90h where code_len is the length
of the code we will use to execute our root shell. 90h is NOP, so we
have been filling up everything with NOPs. since they'll all execute
linearly, we can reasonably throw a precalculated offset for the stack
to return to somewhere in the middle, like 0x2000. next time the
program hits a ret (prolly just after the data input routine that we're
exploiting), it's going to jump to offset 0x2000, run NOPs until it
hits our root shell code, which is just a system call to exec with some
shell code. easier than root shell code is just code to execute
something like "echo toor::0:0::::: >> /etc/passwd" so we can log in
later.
plus, if you're lucky, 0x9090+ will be free for use. so, you just feed
it as many NOPs as possible, with the code somewhere above there. this
means you don't actually need to know the location of the buffer you're
overflowing... useful, if you don't have the source.
> Maybe if you had aliassed segments to allow access by anything to
> anything you could do this easily. But otherwise?
standard case.
> Well... easily? Bit of an understatement <g>. Not only do you need
> the right bytes at the right time, you also need the right buffer to
> overflow so the right bytes get put at the right place. Would still
> be a neat trick.
as illustrated above, almost any buffer, and we already know the exact
bytes we need. as long as you can calculate where that buffer is,
you're set. sometimes you don't even need that. if you don't know
where the buffer is, you'll have to do some kind of code offset
calculation, which is trivial... something like this:
call next:
next: pop bx
sub bx, offset next
; ba-da-bing, you've got the offset of your code.
now instead of doing mov si, offset data
do
lea si, [data+bx]
and everything's totally relocatable.
---
tani hosokawa
river styx internet
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991208153027.G1362>