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 ]

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux