Vulnerability Development mailing list archives
Re: Blind Remote Buffer Overflow
From: sirsyko () ISHIBOO COM (Ralph The Wonder Llama)
Date: Fri Apr 28 22:50:51 2000
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?
I'm not much of a security guru, but I really dont see how much of what you've put into this concept of "blind exploiting" is possible. In order to exploit something, you need to know the vulnerability. The vulnerability has many dependencies: - Machine Architecture - Operating System - Application - What the process behind the application's use of remote input. There are many ways of giving sight to the blind method of attacking. There are many way's of "fingerprinting" a machine to find out its architecture and/or operating system from remote. Its relatively easy to determine the app from remote as well. Once you've determined the arch/os/application, its *typically* easy to find either the source code, or a system you'll have local access to so you can examine the local response to your remote attack. Once you've nailed down the vulnerability and the exploit you are set. I'm pretty sure this answers 100% of the attack process to one degree or another. Part/Most if not All of these steps are usually followed and/or required to generate a successful attack. Without the ability to telekinetically examine the resonse to your attack, this is the method you'll be following. Please knock holes in my process as well :)
Current thread:
- Re: limited functionality accounts (was: Re: History Files), (continued)
- Re: limited functionality accounts (was: Re: History Files) Rob Kouwenberg (Apr 28)
- Re: No-Exec Stack Smashing 101 Granquist, Lamont (Apr 26)
- long file names in explorer.exe kj (Apr 26)
- Re: long file names in explorer.exe Rory Savage (Apr 28)
- Re: long file names in explorer.exe kj (Apr 28)
- Lotus notes + windows98 overflow Alistair Orchard (Apr 27)
- Blind Remote Buffer Overflow Granquist, Lamont (Apr 27)
- Eudora Pro Buffer Overflow testing in progress - help needed. Zoa_Chien (Apr 28)
- Re: Eudora Pro Buffer Overflow testing in progress - help needed. Blue Boar (Apr 28)
- Re: Blind Remote Buffer Overflow Marc (Apr 28)
- Re: Blind Remote Buffer Overflow Ralph The Wonder Llama (Apr 28)
- Re: Blind Remote Buffer Overflow Matthew R. Potter (Apr 28)
- Re: Blind Remote Buffer Overflow Sebastian (Apr 29)
- Re: Blind Remote Buffer Overflow Mark L. Jackson (Apr 29)
- Re: Blind Remote Buffer Overflow Arturo Busleiman (Apr 30)
- Re: Blind Remote Buffer Overflow Arturo Busleiman (Apr 30)
- Replacing Kernel Functions via a LKM Granquist, Lamont (Apr 27)
- Re: Replacing Kernel Functions via a LKM Dragos Ruiu (Apr 27)
- Re: Replacing Kernel Functions via a LKM Dragos Ruiu (Apr 28)
- Re: Replacing Kernel Functions via a LKM Prateek Jetly (Apr 27)
- Re: No-Exec Stack Smashing 101 Michael H. Warfield (Apr 26)