[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] exploitability of off-by-one in motion webserver
From:       Nico Golde <oss-security+ml () ngolde ! de>
Date:       2008-06-11 0:14:22
Message-ID: 20080611001422.GE7320 () ngolde ! de
[Download RAW message or body]


Hi,
* Solar Designer <solar@openwall.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@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic