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
