bugtraq - Re: Buffer overflow prevention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 15 Aug 2003 22:37:57 +0400
From: Solar Designer <solar@...nwall.com>
To: Peter Busser <peter@...steddebian.org>
Subject: Re: Buffer overflow prevention

Hi,

On Fri, Aug 15, 2003 at 11:10:31AM +0200, Peter Busser wrote:
> > you can have all of your stuff run with a
> > non-executeable stack, thus making stack smashing impossible.
> 
> A non-executable stack patch provides no protection.

I am tired of hearing people say both of these things.  Neither is
entirely correct (although the first one is worse).  The facts are:

- non-executable stack doesn't fix any vulnerabilities and doesn't
make them non-exploitable, but

- non-executable stack may provide a layer of protection, making
certain vulnerabilities harder to exploit in the real world.

Non-executable stack, unlike many more advanced hardening measures
(which have similar properties, only being a "thicker" "layer of
protection"), doesn't have a performance impact.  This property, in my
opinion, makes it reasonable to use even despite the fact that the
added protection it brings is very limited.  Whether to also use those
"more advanced hardening measures" may be decided on a case by case
basis.

> It is easy to circumvent.

Most of the time, yes.  Yet this may be an additional bit of work for
an attacker (or exploit writer) and often lower reliability for the
exploit code with remote attacks (a smaller percentage of automated
attacks succeed).

> A few years ago there was a discussion about getting the OpenWall non-exec
> stack patch into Linus' kernel tree and Linus refused. He showed that it was
> easy to circumvent this stuff.

Linus, for obvious reasons, didn't participate in or read all of the
discussions of the topic occurring on public mailing lists.  The
particular attack approach he has pointed out (return-into-libc) was
publicly discussed before that and I was first to post working
exploits relying on this approach to Bugtraq more than a year before
Linus' post (1997 vs. 1998).  I've also included a workaround
preventing some attacks of this nature at the same time (1997).
Others have published even smarter attacks since then.

BTW, I've never raised the question of the patch (not) getting into
the official kernel tree, -- other people did.  I feel that many
over-estimate the importance of that patch (hack?) I did.  I wish some
of their interest in that stuff I've been doing in 1997 would move to
other projects, including Openwall GNU/*/Linux (Owl) which is an
entire OS distribution rather than just a kernel patch.

-- 
Alexander Peslyak <solar@...nwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments