[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080611001422.GE7320@ngolde.de>
Date: Wed, 11 Jun 2008 02:14:22 +0200
From: Nico Golde <oss-security+ml@...lde.de>
To: oss-security@...ts.openwall.com
Cc: coley@...re.org
Subject: Re: exploitability of off-by-one in motion webserver
Hi,
* Solar Designer <solar@...nwall.com> [2008-06-11 01:41]:
> On Tue, Jun 10, 2008 at 06:24:33PM +0200, Nico Golde wrote:
> > 1950 static int read_client(int client_socket, void *userdata, char *auth)
> > ....
> > 1953 int ret = 1;
> > 1954 char buffer[1024] = {'\0'};
> > 1955 int length = 1024;
> ...
> > Overwriting the frame pointer should be not possible since there are variables
> > on the stack before buffer.
>
> You're assuming that all automatic variables are allocated on the stack
> and in-order, but neither has to be the case. The compiler is free to
> place these variables in registers (in which case it might or mIGHT NOT
> also allocate stack space for them), to re-order the variables that it
> does allocate stack space for, and even to optimize some variables out
> if it can.
>
> This means that the frame pointer attack is not out of consideration.
> The risk is there.
True that makes sense. Thanks for pointing this out.
In this case it might be good to have a CVE id allocated for
this. Steve, can you provide one?
> > However it should be possible to overwrite ret with 0 which is used in line 2073 as
> > the return value of the function (normal termination returns 1).
> ...
> > This is the theoretical point but I was not able to reproduce this on
> > a 64bit system. Does anyone have an idea why this could be the case or
> > is even able to reproduce this?
>
> I'd expect "ret" to be placed into a register, or at least cached in a
> register, which explains why you're not able to affect its value. Of
> course, there's no guarantee that it won't be read back from the stack
> in another build, allowing for the attack in case it's also placed right
> above the buffer. (I assume that you're on little-endian.)
Yes this is little-endian(amd64) and having a deeper look at
the generated code you are right as well, this is indeed
place into a register.
> I hope this helps.
Yes it does, thanks for your help!
Cheers
Nico
--
Nico Golde - http://www.ngolde.de - nion@...ber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
