All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Patrick E Kane <kane@urbana.css.mot.com>, linux-kernel@vger.kernel.org
Subject: Re: Stack growing and buffer overflows
Date: Tue, 11 Mar 2003 11:07:03 +0100	[thread overview]
Message-ID: <3E6DB547.4060300@aitel.hist.no> (raw)
In-Reply-To: 20030310172935.A1324@scapula.urbana.css.mot.com

Patrick E Kane wrote:

> I like the idea of turning off execute permission on the stack pages.

It has been shown before that this has these disadvantages:
1. More work settting up those access bits   (bloat & perf. degradation)
2. Some programs actually need an exec stack (loss of features)
3. It don't buy you _any_ security at all!   (didn't help anyway)

About (3): Of course it stops some of the current exploits, but there is
a trivial way to "enhance" stack-smashing exploits to work around the
non-exec stack:

You can still overwrite the function's return address, on that non-exec 
stack.  The cracker can no longer upload code and make the function 
return to that, but crackers don't need to!  All they need is to return 
to a place containing exec("/bin/sh") *and such places exist*, 
paritcularly in every program using libc.  So writing the the exploit
becomes a little harder, using it is as trivial as ever.

Spend the time fixing broken apps, or get them right from the start.  It 
is not as if writing safe C is _hard_.

Helge Hafting



  reply	other threads:[~2003-03-11  9:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-10 23:00 Stack growing and buffer overflows Felipe Alfaro Solana
2003-03-10 23:29 ` Patrick E Kane
2003-03-11 10:07   ` Helge Hafting [this message]
2003-03-11 12:23 ` =?unknown-8bit?Q?J=F6rn?= Engel

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=3E6DB547.4060300@aitel.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=kane@urbana.css.mot.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.