[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