> On Thu, 30 Dec 1999, Theodore Y. Ts'o wrote:
> > In any case, I suspect that if something randomly added some random
> > value between 0 and 128k to the stack pointer at startup time, it would
> > also go a fairly long way towards thwarting overrun attacks --- but make
> > no mistake, it's still only papering over the problem.
>
> But is "it wont work 100% of the time" a good enough reason to discard the
> idea out of hand entirely? The fact we cant raise the bar infinitely high
> means we shouldnt raise it even a little?
No, we instead raise the bar by writing better code.
By the way, it's possible to write instrumented versions of the string,
environment and I/O functions that can keep track of untrusted data and
potential overflows. If your program is compiled without inline functions,
they can even be put in a preloadable DLL. As 99% of string manipulation
happens either in place or with the use of library functions, this will
catch most things if you manage to get good code coverage.
I wrote something that did just this a few summers ago. It kept track of
potentially tainted regions of memory as well as file handles associated
with untrusted files. Combined with something like Electric Fence, it
might even be able to find potential heap overflows.
Unfortunately, fixed-sized hash tables don't work very well for tracking
the taint data and I never got around to writing the tree-based version,
so it's never gotten past the experimental stage.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/