Re: Blind Remote Buffer Overflow

[vision () WHITEHATS COM (Max Vision)]

`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:lamont () ICOPYRIGHT COM]
> Sent: Thursday, April 27, 2000 6:47 PM
> To: VULN-DEV () SECURITYFOCUS 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?