Re: mod_proxy and HTTP 302 response

Graham Leggett wrote:

> Brett Hutley wrote:
>
>> Kinda works like strdup() as far as I can see... (although I guess 
>> with a memory pool)...
>
>
>>    len = strlen(s) + 1;
>>    res = apr_palloc(a, len);
>>    memcpy(res, s, len);
>
>
> The apr_palloc() will either allocate enough memory for a (potentially 
> very large) string, or it will segfault (to my knowledge) and fail 
> safe. Thus the memcpy will only occur if a buffer is created 
> sufficiently large enough to hold the string, thus no overflow that I 
> can see.
>
> Again - can someone else check...?

No, the point I was trying to make was not of a potential overflow, but 
the ability to store whatever you want in
an area of memory - including machine code. If you had a *different* 
buffer overflow attack, but didn't have
enough of a buffer to store your exploit machine code, then you could 
potentially use this area of memory to
hold your exploit machine code as binary data and then indirect to it 
using your buffer overflow attack. For example,
lets say that you had created a server that send "HTTP/1.1 200 ..." 
where the dots are the machine code for a function that does a 
system("tftp ...") or whatever. The machine code is essentially 
strdup()ed, and you now know that if you can indirect through to that 
area of memory, ie (*request_rec->status_line)(); you can execute your 
exploit code. Of course this depends on you being able to make a buffer 
overflow attack on *another* function that gets the request_rec pointer. 
So it is very very unlikely that this is a real vulnerability.

Cheers, Brett