OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Blind Remote Buffer Overflow
From: Max Vision (visionWHITEHATS.COM)
Date: Sat Apr 29 2000 - 01:43:06 CDT

`man ulimit`

On Fri, 28 Apr 2000, Drissel, James W. wrote:
> Some protection could be had by making sure that any core dumps that do
> occur are dumped to a directory that is not under the webroot. This would
> raise the bar on detecting that a core dump had occurred at all.
> Alternatively, you could have a process that looks for core files and moves
> them when they are found.
>
> Or if you wanted to be really devious, put a core file in each directory
> (set permissions so that it can't be overwritten), but use a core from some
> other architecture or just a file with totally random data in it. This
> might have the attackers pulling their hair out! Just think about the
> hacker pulling his hair out looking at a linux xterm core when they tried to
> overflow something else on a box that nmap reports as a Sun...
>
> James Drissel
>
> -----Original Message-----
> From: Granquist, Lamont [mailto:lamontICOPYRIGHT.COM]
> Sent: Thursday, April 27, 2000 6:47 PM
> To: VULN-DEVSECURITYFOCUS.COM
> Subject: Blind Remote Buffer Overflow
>
>
> What does a theoretically feasible attack of this nature look like? Lets
> say that you're up against a webserver that runs some CGI C. How do you
> find and exploit a buffer overflow without having access to the code?
>
> It seems that you first need to find a buffer overflow. What is the
> symptom here because when you dump core on one httpd proc then you'll just
> spawn another one. The service doesn't go down, so how do you know you
> just caused the proc to core?
>
> Then once you've found a buffer overflow, I guess you need to start
> blindly guessing buffer sizes and locations until you get a winning
> combination -- here the fact that webservers respawn would decidedly work
> to your advantage. You can also probably bet that the buffer size is damn
> close to whatever size causes the proc to core, if you can determine that.
>
> Can anyone flesh this out further, or knock big holes in this process, or
> think of a radically different approach which is better? Then, how can
> you make it even harder to exploit these kinds of holes blindly?
>