[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: Solar Designer <solar () openwall ! com>
Date: 2008-06-10 23:29:06
Message-ID: 20080610232906.GA4586 () openwall ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic