[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120515122858.GF10671@suse.de>
Date: Tue, 15 May 2012 14:28:58 +0200
From: Marcus Meissner <meissner@...e.de>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>,
Keegan McAllister <mcallister.keegan@...il.com>
Subject: Re: Automatic binary hardening with Autoconf
On Tue, May 15, 2012 at 08:13:31AM -0400, Steve Grubb wrote:
...
> > Also interesting are the performance impact numbers (up to 30%), which
> > are far worse than those I've seen posted before (up to 5.8%):
> >
> > http://d-sbd.alioth.debian.org/www/?page=pax_pie
>
> This is because the stack canary is a random number. Imagine adding a "function
> call" between every intended function call to grab a random number. Because of
> this, we want sensible security. You have to live with the performance hit or
> have some heuristic that you use to decide which apps get the special treatment.
The stack random number is coming via AT_RANDOM ELF aux vector, but
yes, the %gs:xxx -> stack write based setup is of course swallowing time.
> Also, I have been studying the stack-protector, FORTIFY_SOURCE, ASLR (which is
> how I found the ASLR bypass for fs capability programs recently), and RELRO. It
> turns out there are many holes in the protection we all expect is working. Not
> mentioned in the blog is the fact that with compiler optimizations being on,
> stack-protector and FORTIFY_SOURCE do not work. There are many other loopholes,
> like an array of structs do not get any stack-protector treatment. Nor do arrays
> of ints. And the stack-protector is only checked on function exit. So, you may
> have a function that gets overflowed and passes corrupted variables around and it
> may do something irreversable like call execve or create a file based on those.
Yes, some stuff can get the -fstack-protector-all treatment for this to facilitate
all function, but of course most of your notes still apply.
It is a heuristic, and getting it more complete might be easy, or might get
difficult.
> We found that compiler flags alone were not enough. For example, if you want to
> set partial RELRO to be the default, there are a large number of programs which
> do not take the LD_FLAGS environmental variable. The common fix appears to be to
> patch binutils to add partial RELRO on all linking.
SUSE has changed binutils on our request to default to "-z relro",
so applications do not need to care about that anymore.
"-z now" we did not dare to force yet, as it does cause slow downs.
> I created a shell script that can be used to "grade" an installed system based
> on my own policy. http://people.redhat.com/sgrubb/files/rpm-chksec
>
> This will take an rpm name as input and verify each ELF file to see if its
> compiled with the intended flags to most effectively use PIE and RELRO. Green is
> good, Orange could use work but is acceptable, and Red needs fixing. It has a
> mode --all that is the equivalent of using rpm -qa and feeding the packages to
> it. In this mode it will only give a summary result for the package. To find
> which files don't comply, re-run using just the package name.
Hook it into rpmlint ... :)
Ciao, Marcus
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
