5:52 a.m.
Hi,
I just read this interesting article on lwn:
http://lwn.net/Articles/106214/
(lwn subscriber only)
This talks about things like:
1 Stack Smash Protection
2 PAX (alternative Exec Shield)
3 Position Independent Executables.
Stack Smash Protection sounds like a cool feature to me. I don't know
what the performance impact is, but as a developer even if it is to slow
to use by default I would love to have it intergrated into the gcc
shipped by Fedora to make debugging easier.
PAX uses tricks to get a non executable stack, and assignes random
addresses to PIE executables, which Fedora already has in the form of
Exec Shield, good! But if I undertand it correctly PAX does more for
example also make data pages non executable, this might be something
worth looking into.
PIE we already have, good!
Regards,
Hans
6:11 a.m.
Stack Smash Protection sounds like a cool feature to me. I don't
know
what the performance impact is, but as a developer even if it is to slow
to use by default I would love to have it intergrated into the gcc
shipped by Fedora to make debugging easier.
I use a specially doctored version of gcc with propolice compiled in. I have
helped code review & submit corrections to propolice. I can say that its pretty
good, but not bulletproof. Its worth adding for the fact that it is one more
layer should there be holes in the other protection mechanisms. Performance is
pretty good. 5-10% performance hit. However, there is one small issue. It needs
to read from /dev/random and write to /dev/syslog. This is not in all policies
and has to be manually added. I see the avc messages all the time.
I also use libsafe which seems to catch more stack smashing attempts than
propolice. I have corrected a number of bugs in it and shared them with the
developers. I also extended libsafe to cover more vectors of attack. You can find
the updated copy here: www.web-insights.net/libsafe. There is a perfomance hit,
but its small. I'd rather a 2 Ghz machine with cycles to burn run with libsafe +
propolice than spend 2 days setting up the machine after its hacked. libsafe does
use an LDPRELOAD variable to intercept calls. This means that it offers no
protection to setuid/setgid programs. selinux may also object to it.
But if I undertand it correctly PAX does more for example also make
data
pages non executable, this might be something worth looking into.
Some of the things it does makes software debug impossible. valgrind sometimes
has problems with it. I think there are some bits of it that are good, as well as
the openwall linux patch set. It would be better if these were adopted into the
kernel rather than maintained as a patch to it.
But something that neither of these address, is plain logic errors. Every week I
find a pretty good problem that scanners (flawfinder/lint/valgrind), stack
protectors (propolice/libsafe), and se linux cannot catch. Part of the solution
has to be peer review.
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
10:09 a.m.
On Thu, 2004-10-14 at 06:52, Hans de Goede wrote:
Stack Smash Protection sounds like a cool feature to me. I don't
know
what the performance impact is, but as a developer even if it is to slow
to use by default I would love to have it intergrated into the gcc
shipped by Fedora to make debugging easier.
you can use jakub's gcc 4 / glibc rpms and something like this too
PAX uses tricks to get a non executable stack, and assignes random
addresses to PIE executables, which Fedora already has in the form of
Exec Shield, good! But if I undertand it correctly PAX does more for
example also make data pages non executable, this might be something
worth looking into.
execshield makes data pages also non executable
11:17 a.m.
Arjan van de Ven wrote:
On Thu, 2004-10-14 at 06:52, Hans de Goede wrote:
>Stack Smash Protection sounds like a cool feature to me. I don't know
>what the performance impact is, but as a developer even if it is to slow
>to use by default I would love to have it intergrated into the gcc
>shipped by Fedora to make debugging easier.
you can use jakub's gcc 4 / glibc rpms and something like this too
You mean the default RPM's in FC3 or ... ?
and how do I do this something like this?
Thanks,
Hans
12:54 p.m.
On Thu, Oct 14, 2004 at 06:17:41PM +0200, Hans de Goede wrote:
Arjan van de Ven wrote:
>On Thu, 2004-10-14 at 06:52, Hans de Goede wrote:
>
>>Stack Smash Protection sounds like a cool feature to me. I don't know
>>what the performance impact is, but as a developer even if it is to slow
>>to use by default I would love to have it intergrated into the gcc
>>shipped by Fedora to make debugging easier.
>
>
>you can use jakub's gcc 4 / glibc rpms and something like this too
>
You mean the default RPM's in FC3 or ... ?
and how do I do this something like this?
You can compile with CC=gcc4 CFLAGS=-fmudflap LDFLAGS=-lmudflap to get
instrumented binaries. You'll need to install the libmudflap packages
to get that to work.
Tim.
*/
1:45 p.m.
Hans de Goede <j.w.r.degoede <at> hhs.nl> writes:
Hi,
I just read this interesting article on lwn:
http://lwn.net/Articles/106214/
(lwn subscriber only)
Yay :)
This talks about things like:
1 Stack Smash Protection
2 PAX (alternative Exec Shield)
3 Position Independent Executables.
Stack Smash Protection sounds like a cool feature to me. I don't know
what the performance impact is, but as a developer even if it is to slow
to use by default I would love to have it intergrated into the gcc
shipped by Fedora to make debugging easier.
I use it.
The performance impact isn't noticable, but it's highly variable. It's
theoretical maximum is something like 8%; and it drops when a function
gets bigger, or when functions aren't protected.
You can use heuristics (-fstack-protector) to protect only functions
with a local character array; or just protect all
(-fstack-protector-all). With the heuristics, it's likely you don't
much encounter protected functions.
My best guess looking at the design (not the code) is that it takes
about 4 instructions to protect a function on the base, plus one more
per passed argument, based on the below.
SSP rearranges variables at compile time. This produces no runtime
overhead.
SSP protects a function with a local char[] using a __guard value.
This would require expanding the stack frame. The best way is to
allocate the entire stack frame at once, so I assume the GCC devs
are smart and that this produces 0 extra instructions. Next, you
need to check the GOT for __guard (I'm assuming O(1), so one
instruction), and use MOV to copy __guard to local_guard (1 insn).
At return in a protected function, __guard must be checked with
CMP. If it's fine, then JE past the code that calls
__stack_smash_handler(). Two more instructions. This totals 4
for a __guard protection on a function.
To protect passed arguments, the stack frame has to be made bigger
(no overhead?). A MOV based on an offset from an address in some
register has to be made for each argument (1 insn for each argument).
I'm guessing at internals, but I think most of this is possible. I'm
not sure about the O(1) GOT lookup. I'm probably wrong there.
PAX uses tricks to get a non executable stack, and assignes random
addresses to PIE executables, which Fedora already has in the form of
Exec Shield, good! But if I undertand it correctly PAX does more for
example also make data pages non executable, this might be something
worth looking into.
PaX makes a strict separation between Writable and Executable memory.
It also has more accurate NX emulation on x86. Ingo has admitted that
PaX is competetive with Exec Shield in recent LKML posts:
(but no doubt PaX is fine and protects against exploits at least as
effectively as (and in some cases more effectively than) exec-shield,
so you've definitely not made a bad choice.)
It's also older and still actively developed (older and inactive is
bad, older and active is good, younger and active is not quite as good
unless your developer is quite a lot more competant on the subject).
SEGMEXEC on x86 splits the address space in half to emulate an NX bit;
I've never seen this cause a problem in anything. PAGEEXEC used to
use kernel-assisted MMU walking, which can be very high overhead
depending on memory access patterns; now it uses the same method
Exec Shield uses, but falls back to kernel-assisted MMU walking if
that fails (due to mprotect()ing a higher address with PROT_EXEC).
PIE we already have, good!
Feh, your PIE is a joke. My ENTIRE SYSTEM is PIE, save for what
won't compile PIE. I don't use Fedora, but last I heard, only a
few programs were PIE.
The overhead of PIC (based on nbyte-bench) is something like
0.99002% on x86, and 0.02% on amd64. There's another caveat:
-fomit-frame-pointer usually gives a -5% overhead (i.e. it removes
overhead and thus programs use less CPU). This is lost on x86; no
effect (ok, 0.01%) on amd64.
That being said, you have to understand that libraries are ALL PIC.
You lose NOTHING in libraries by going to PIE. All plug-ins to
anything (except gimp?), all encoder and decoder libraries,
libtheora, libogg, libvorbis, libvorbisenc, liblame, libmad,
libzlib and libbzip2, ALL YOUR HEAVY LIFTING is done in libraries.
I haven't profiled it but I'm fairly sure that any large amounts of
CPU are typically spent in PIC code anyway. I'm pretty certain
that the real-world system-wide impact of PIE is dismally low due
to the low amount of time the actual executable load module spends
on the CPU versus the libraries it uses.
Regards,
Hans
3:49 p.m.
Stack Smash Protection sounds like a cool feature to me. I don't
know
what the performance impact is, but as a developer even if it is to slow
to use by default I would love to have it intergrated into the gcc
shipped by Fedora to make debugging easier.
well.. gcc in fc4 (well rawhide right now) has something that has a
quite similar effect, with basically zero performance impact.
Try it ;)
PAX uses tricks to get a non executable stack, and assignes random
addresses to PIE executables, which Fedora already has in the form of
Exec Shield, good! But if I undertand it correctly PAX does more for
example also make data pages non executable, this might be something
worth looking into.
Exec-Shield makes datapages also non-executable. There is very little
practical difference between PAX and Exec-Shield protection wise. There
are theoretical differences, mostly comming from a different viewpoint
(Exec-Shield is about being as secure as possible without breaking
things, while PaX does make the deliberate choice to break things. The
difference is small, the things that "break" are rare. very rare.)
The reason Exec-Shield does this is because the worst thing that can
happen is to be too secure, so secure that all sysadmins just turn it
off entirely.
7035
days inactive
7132
days old
8 comments
5 participants
participants (5)
-
Arjan van de Ven -
Hans de Goede -
John Richard Moser -
Steve G -
Tim Waugh