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
next prev parent 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.