public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jeremy Jackson <jeremy.jackson@sympatico.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Is this the ultimate stack-smash fix?
Date: 14 Feb 2001 22:30:05 -0700	[thread overview]
Message-ID: <m1hf1w8qea.fsf@frodo.biederman.org> (raw)
In-Reply-To: <3A899FEB.D54ABBC7@sympatico.ca> <m1lmr98c5t.fsf@frodo.biederman.org> <3A8ADA30.2936D3B1@sympatico.ca>
In-Reply-To: Jeremy Jackson's message of "Wed, 14 Feb 2001 14:19:12 -0500"

Jeremy Jackson <jeremy.jackson@sympatico.ca> writes:

> "Eric W. Biederman" wrote:
> 
> > Jeremy Jackson <jeremy.jackson@sympatico.ca> writes:
> > (about non-executable stack)
> >
> > There is another much more effective solution in the works.  The C
> > standard allows bounds checking of arrays.  So it is quite possible
> > for the compiler itself to check this in a combination of run-time and
> > compile-time checks.   I haven't followed up but not too long ago
> > there was an effort to add this as an option to gcc.  If you really
> > want this fixed that is the direction to go.  Then buffer overflow
> > exploits become virtually impossible.
> >
> 
> I've thought some more, and yes someone else has already done this.  Problems
> are with compilers that
> put code on stack (g++ trampolines for local functions i think).  There is
> the gcc-mod (Stack-guard?) that checks for
> corrupt stack frame using magic number containing zeros before returning...
> this will take away some
> performance though...

No.  I'm not talking about stack-guard patches.  I'm talking about bounds checking.
The difference here is that if correct code is generated you won't
overflow any buffer at all period.  The compiler will either prove at
compile time that it can't happen (The efficient case).  Or it will
generate pointers as <start,length,offset> tuples into chunks of
memory.  And it will do runtime checks that will that will kill your
program if it overflows the stack.  I think the gcc options is -fcheck
or something like that.  I haven't had a chance to follow up, since I
saw that someone was actually working on it.

Since compilers bugs happen buffer overflow exploits are still
possible but it means two separate programmers must mess up in
complimentary ways.

As for fine grain privileges they can help, but the real fix is to
keep the programs that need raised privileges down to one function.
Letting you look at the program and see if it is obviously correct
with no security bugs. 

But the gcc bounds checking work is the ultimate buffer overflow fix.
You can recompile all of your trusted applications, and libraries with
it and be safe from one source of bugs.

Eric

  parent reply	other threads:[~2001-02-15 15:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-13 20:58 Is this the ultimate stack-smash fix? Jeremy Jackson
2001-02-13 21:06 ` Alan Cox
2001-02-13 21:22 ` James Sutherland
2001-02-13 23:04   ` Bruce Harada
2001-02-13 23:14 ` William T Wilson
2001-02-14 16:25 ` Eric W. Biederman
2001-02-14 19:19   ` Jeremy Jackson
2001-02-14 20:43     ` Gerhard Mack
2001-02-15  5:30     ` Eric W. Biederman [this message]
2001-02-15 15:29       ` Manfred Spraul
2001-02-15 16:00         ` Eric W. Biederman
2001-02-17 14:43           ` Peter Samuelson
2001-02-18  4:53             ` Eric W. Biederman
2001-02-20  1:10               ` Andreas Bombe
2001-02-20  9:09                 ` Xavier Bestel
2001-02-20 16:40                   ` Jeremy Jackson
2001-02-20 17:04                     ` Xavier Bestel
2001-02-21  0:13                   ` Andreas Bombe
2001-02-21  9:30                     ` Xavier Bestel
2001-02-15 15:32       ` Jeremy Jackson
2001-02-17 10:47   ` Florian Weimer
2001-02-17 20:32     ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1hf1w8qea.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=jeremy.jackson@sympatico.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox