Buffer Overflow Attacks

[520065607613-0001@t-online.de (Frank Pilhofer)]

   Hi,

 beware, the following text contains an idea on a topic that I am not
an expert on and which I have not extensively researched, so it's one
of the usual cases where someone comes along with dangerous half know-
ledge. So ignore me if the following does not make any sense at all.

 A few days ago, I have once again read an article about attacking
systems on the Internet using various kinds of exploits. Seems to me
that apart from braindead administrators, the usual entry into a sys-
tem is by exploiting a buffer overflow error.

 Despite extensive peer review and linkers that warn us about gets(),
new buffer overflow errors in popular software are discovered again
and again.

 If my limited comprehension of this topic is correct, buffer over-
flow exploits are based on the fact that you can overwrite vital parts
like processor registers and a function's return address, which are
stored on the stack just as local variables are.

 So I had the idea whether it would be possible to avoid buffer over-
flow vulnerabilities by using two separate stacks, one for data and
the other for registers and addresses. This is work that could be done
with the compiler and the linker.

 This idea would not work if it is not possible to have two stack seg-
ments. You could place the two parts into different address ranges of
the stack segment, though. If the registers/addresses parts is on a
smaller virtual address, your program would likely run out of real
memory whilst the attacker sends data before the wrap-around occurs
(or fail upon hitting a read-only address).

 Another alternative would be to introduce some randomness in the
usage of stack data. Exploits only work well because we have large
OS distributions that put the same executable onto hundreds of
thousands of machines. But even compiling the same program with
different compiler options makes a difference, e.g. compiling with
or without debugging, invalidating the exploit, doesn't it?

 Some ideas that come to my mind for this topic are e.g. random
padding on the stack (e.g. upon a function call, you add a couple
of bytes more or less), or maybe xor'ing the register values on
the stack with a per-process random number.

 So basically, I am wondering if the compiler could do something to
blunt buffer overflow attacks. I know, that is not the prime purpose
of the compiler but rather the responsibility of the programmer, but
still I find it an attractive idea as a one-step fix for all such
exploits.

 Okay, that's enough for now. If you've read so far, it's either because
there is some sense in my ideas, or because you were getting a good laugh
out of it.

 Any comments?

	Frank



-- 
Frank Pilhofer  ...........................................  fp@fpx.de
A family vacation is when you go away with people you need to get
away from. - Alfred E. Neuman