[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Jun 2008 03:29:06 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: exploitability of off-by-one in motion webserver
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.
> 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.)
I hope this helps.
Alexander
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.
