full-disclosure - 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] [thread-next>] [day] [month] [year] [list]

From: peter at trusteddebian.org (Peter Busser)
Subject: Re: Buffer overflow prevention

Hi!

> > Also, you can use chpax, and turn on a non-executable stack, and with a small
> > amount of voodoo (in tracking down the binarys and .so's that need the stack,
> > wich typically is only a single binary or .so file, wich you can find with
> > ptrace, strace, or ltrace) you can have all of your stuff run with a
> > non-executeable stack, thus making stack smashing impossible. Nothing can
> > execute off your stack so a malicous person can override all the addresses he
> > wants, his code cant run off your stack.
> >
> It's been proved many times that non-executable stack adds NO security at
> all.

It does provide some form security, but only a really tiny amount.

The difference here is that PaX does much more than just implement a
non-executable stack. It also tries to separate code from data, it randomises
several address bases and also protects the kernel memory.

You can see most differences between the different memory protection patches
by running the paxtest program I wrote. You can download it from the PaX site
(http://pageexec.virtualave.net/) or install it using apt-get install if you
are running Adamantix.

[about SSP, aka ProPolice]
> Beside that it's an existing, well tested and wide used (for example
> OpenBSD uses it by default now).
> I see no real reason why the major Linux companies are not using it for
> its products.

There is no reason, all this stuff (SSP and PaX) is working beautifully on many
Adamantix boxes. I think there are several reasons why the major Linux
distributions do not incorporate this stuff.

One is inertia: Our distribution is already secure. After all, we release
updates in a timely manner after they are discovered. We have always done that,
and everyone else does it like that.

Another one is the NIH-syndrom, of which Red Hat is an example. Instead of
simply taking PaX, which is at this moment the nr. 1 patch in the protection
it offers, Ingo Molnar decided to create his own patch which is called
execshield. This execshield does not provide the same level of protection PaX
does.

And another is that performance is more important than security in the Linux
world. Even though most servers and desktops are more than 90% idle and CPU
cycles have never been so cheap. Still, it seems that none of this wealth
should be spent to improve security somewhat.

Adding security is a lot of hard work and noone will notice when you do it
right. This is simply not the most sexy and profitable thing. Especially for
commercial Linux distributions it pays of more to add stuff to the user
interface than to spend a lot of time (and money) on adding more security.

These are of course only a few of the reasons.

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/