Practical remote execution of buffer overflow exploits?

I've been reading alot into buffer overflow exploits recently, and I'm pretty sure I have a good grasp of the theory and techniques...but I just got to wondering something that I cant seem to figure out:

Why is so much importance placed on fixing and preventing these programming mistakes? How would a remote attacker take advantage of an exploit like this without already having broken into another computer just under a non-root account?
Would it not be easier and more practical to place all the more emphasis on preventing an attacker from getting acces to a command prompt on your computer? Or is there some sort of indirect way an attacker can use an exploit such as a buffer overflow to immediately take over a computer without any previous access?

Heh sorry for all the questions, if this is too newbish of a thread, I sincerely apologize....
Anyways, thanks in advance for any responses :)

There are two parts to a buffer overflow attack. The overflow itself and the code that is injected into the stack or heap known as the payload. The overflow will work remotely, without any credentials and the payload will often be run in the context of the system since that is what the service that was overflowed was running in, (though this isn't always the case and can vary quite considerably).

The command prompt is often irelevant since the payload will allow the attacker to connect and run code of his own making. Usually it will first be used to ftp files in to the system that the attacker wants to use.

I am sorry to say this dude but you don't have grasp over this subject at all probably u read the definition of a buffer overflow only. Ok suppose we find a beffer over flow in a system call or say a dll when u call that call or subroutine or a dll from ur program then there is always a return address associated with that subroutine.

take a exapmle:

void myfun()
{
char mystr[10];
gets(mystr);
.....//some more instructions;
}
int main()
{
lame();
return 0;
}
complie it and run(i did on linux)

here is whathappens:
asdffdfsfhsfhshfsjhfhudjhfsdhfjshfshfshfhsffsfjshfjshfjhsfsfjhsjfsjhf <----this is my input

segmentation fault

see in normal case of a buffer over flow subroutine returns to its return address that is why it was harmless here
but what if a attacker finds a buffer overflow in a dll on say IIS 6 .
what can happen?
he can change the return address of subroutine with asm and c programming and cause the subroutine to return to a perticular adress thus execute his own code with the priviledge of ...OS.... !
there is so much to say about buffer overflow and exploit just go to www.google.com and search for buffer overflow + exploit .
Oh by the way it is midnight here i am really tired so forgive me for any mistakes in this reply PPL here on antionline are really cruel they don't spare anyone and specially a peson with newbie next to his name.

Thank you so much for your responses.
sforce: you're definitely right, I really dont have a grasp over the subject at all I guess...I understand the concept, and can follow the code of the simplest of exploits, but thats about it...
But your post and the IIS comment really cleared things up for me, thank you for your help :)

Ive been thinking of buffer overflows only in their most simple form, as a program that takes an argument at runtime that isn't bounds checked. I completely overlooked the possibility of a program run through a network that has buffer overflow vulnerabilities in subroutines or dlls etc..
Sorry about the hassle, but thanks alot for the help :) I'll go read some more haha

Quote:

---

Ive been thinking of buffer overflows only in their most simple form, as a program that takes an argument at runtime that isn't bounds checked. I completely overlooked the possibility of a program run through a network that has buffer overflow vulnerabilities in subroutines or dlls etc..

---

Well a buffer overflow can be as simple as writting a batch file which will run as soon as the windows starts, then have it create an endless amount of folders for example in the desktop, or have it pop up endless messages :)...well thats more of a denial of service but you can use your imagination.

One of two things can happen, System Crashes or you open a back door.

Quote:

---

The command prompt is often irelevant since the payload will allow the attacker to connect and run code of his own making. Usually it will first be used to ftp files in to the system that the attacker wants to use.

---

Get ready for a deeper attack?

Quote:

---

Originally posted here by Cybr1d
Well a buffer overflow can be as simple as writting a batch file which will run as soon as the windows starts, then have it create an endless amount of folders for example in the desktop, or have it pop up endless messages :)...well thats more of a denial of service but you can use your imagination.

---

No its not... and also I beleave windows may have limits as to how many sub-folders and things certian directories can hold. But even if im wrong about that, how is this in any way involveing buffer overflows... or playing around with malformed inputs to programs in general?

Quote:

---

Why is so much importance placed on fixing and preventing these programming mistakes? How would a remote attacker take advantage of an exploit like this without already having broken into another computer just under a non-root account?

---

Errrr.... wtf. I beleave you already know why these programing mistakes is of "so much importance". You're exploiting a program... you gain whatever rights or priviledges it has :mad:.

Quote:

---

PPL here on antionline are really cruel they don't spare anyone and specially a peson with newbie next to his name.

---

AOers are nice... I on the other hand am a basterd and a violent criminal. If you dont like AOers then why post here...

thespecialist: haha , yah..."Errrr.... wtf." is right I guess. Its not that hard of a problem to prevent with a bit of extra care when programming, I was just viewing it as more of a secondary problem that could be prevented altogther if command line access to the programs was made much more difficult to attain.

The point is that you don't need command line access at all. If you have the same level of access as a program that you are exploiting and that program happens to basically have admin rights (for whatever reason), that means that you can basically do what you want to that computer.

Think about it for a second: say you want to create a text file, do you think you need to use a utility like notepad, edit, vi or something else? If you do, then ask yourself, "how does that program create the text file for me?" The answer is that it performs file i/o. If you then think to yourself a bit more and ask how does file i/o take place, you get the answer that some more low level operation comes into play. Now if you can insert some machine code (we'll call it that for the sake of "concept") you can basically perform any operation on the computer that is possible.

[edit] ignore the "same level of access" part of it, god knows how that got into my post :) [/edit]

ac