Vulnerability Development mailing list archives
Re: Blind Remote Buffer Overflow
From: james.drissel () CMET AF MIL (Drissel, James W.)
Date: Fri, 28 Apr 2000 10:20:20 -0500
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?
Current thread:
- Re: Blind Remote Buffer Overflow Drissel, James W. (Apr 28)
- Re: Blind Remote Buffer Overflow Max Vision (Apr 28)