Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Jun 2008 02:14:22 +0200
From: Nico Golde <>
Subject: Re: exploitability of off-by-one in motion webserver

* Solar Designer <> [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!

Nico Golde - - - 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.