Thank you for the excellent description of buffer overflows! :)
hmmm, makes me wonder if any talented malicious hackers have designed
algorithms to automatically determine the memory layout without manual
testing and retesting? It would be then the Java of hackerdom...sort of
like "write once...destroy everywhere". For example, you'd have sort of
a hacker virtual machine (HVM) that is inserted into the overflow area
of the code. When executed, the HVM then lays out the parent computer's
file system and then with root privileges, executes malicious or
beneficial programs that the HVM can download from the net or on a local
drive or unzipped alongside the HVM. The hacker could write operating
system agnostic code which would be run by the HVM bytecode
interpreter. I'm sure there could be a non-maliscious application of
this, like for self-healing purposes, but I can't think of any, because
it would be better to just replace the overflow-causing bug.
On Mon, 2003-07-28 at 18:59, Paul M Foster wrote:
> On Mon, Jul 28, 2003 at 03:14:14PM -0400, Eric Jahn wrote:
>
> > Thanks, but what about a program trying to allocate more data than there
> > is space for could allow a vulnerability which could incapacitate the
> > whole system? Shouldn't any operating system stop this? I know that
> > buffer overflows are a big problem in any operating system, but why?
>
> Here's why. Let's say you write C code that allocates a buffer of 100
> bytes to a string variable. Now, C doesn't actually put a limit on the
> buffer. You have a gentleman's agreement with C not to go over that
> limit. But let's say part of your program accepts input into this
> buffer. And let's say that you don't perform any checks to ensure that
> you're not stuffing more characters in that buffer than it can hold. So
> you come along and start giving the program input, and you go over your
> 100 byte limit. Now you're overwriting something else that was at the
> end of your variable's buffer. You might think that the OS will catch
> this, but the truth is that the OS allocates X memory to your program,
> and it doesn't care what you do with it. Now, if you managed to write
> into memory owned by another program, the OS might do something about
> it. But if you overstuff your own buffer, the OS looks the other way.
>
> So you've overstuffed your buffer. What's outside your buffer that you
> overwrote with your input? Who knows? If it's the stack, you've just
> hosed your program. If it's the heap, it could do the same thing. But
> what if the area you overwrote was some executable code from your
> program? Your program will probably crash one way or another. But let's
> say that you're a particularly talented hacker. When you were inputting
> things you worked it out so the characters you overfilled your buffer
> with just happen to represent real executable code that does something
> malicious, instead of random characters. Now you've got an exploit.
> Sometimes hackers will test a program for this kind of thing over and
> over until they find out how the memory is laid out, and then feed in
> instructions they know will do something bad.
>
> As mentioned, Java and the like actually test array boundaries and such
> in the background, so it isn't a problem. But C and C++ programmers have
> to do this themselves, and often they don't.
>
> Paul
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:00:26 EDT