Linux-kernel mailing list archive 1998-31,: Re: Stack Smashing and no-exec

# Re: Stack Smashing and no-exec

Kragen (kragen@pobox.com)
Sat, 8 Aug 1998 11:07:23 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dominik Weis: "Re: pseudo-tty problems w/2.1.115"
- Previous message: Dave Airlie: "Re: output of ksymoops for wabi bug ..."

On Sat, 8 Aug 1998, Jon M. Taylor wrote:
> On Fri, 7 Aug 1998, Kragen wrote:
> > No, that wasn't what I meant. If you have a compiler that does
> > bounds-checking in a reliable fashion, you may indeed be able to avoid
> > adding features to the code to make sure it doesn't buffer-overflow.
> > In fact, you might be better off that way.
>
> This sort of checking cannot be made deterministic, though, right?

Run-time bounds checking can work reliably, yes. Compile-time
bounds-checking -- well, it *could*, but it would be impractical. I
was talking about compilers that insert reliable run-time bounds-checks
into programs, like the recent modifications to gcc.

> > What I meant was that there are (many!) other security bugs that are
> > not the result of wild pointers, and so you can't rely on your compiler
> > to catch them.
>
> That is also true. It may be harder to imagine a bug which makes
> a suid root program fall over and spew garbage all over /proc/kmem, but it
> is not impossible. Should the kernel watch for this? No, it assumes that
> suid root code knows what it is doing. That means no special treatment.

Janus is another interesting approach. You can run your suid-root code
under a monitor which knows, for instance, that the only thing `named'
is supposed to `execve' is `named-xfer', and denies any other `execve's
from named.

> I think you could say that if the stack-smashing thing isn't a problem for
> non-root code, it just plain is not a bug period, at least not in the same
> sense.

I don't know. Bugs are relative to requirements; if a program meets
its requirements perfectly, then it has no bugs. If my requirements
for a non-root program do not include reporting errors when too-long
inputs are given (that is, "Segmentation Fault" is an acceptable error
message), then buffer-overflows aren't necessarily bugs.

Kragen

-
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.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: Dominik Weis: "Re: pseudo-tty problems w/2.1.115"
- Previous message: Dave Airlie: "Re: output of ksymoops for wabi bug ..."