A start

T_B T_B at sympatico.ca
Sun Jan 11 14:48:44 PST 2004


"Robert Connolly" <cendres at videotron.ca> wrote in message
news:200401111547.25938.cendres at videotron.ca...
>
> Your second test should fail, unless you have -fstack-protector-all in the
> specs file.
>

That was it, the specs file had -fstack-protector-all.
I now get the following correct results:

[/usr/src]# hgcc -r
            Restoring GCC Specs File

[/usr/src]# hgcc -V
            Hardened Gnu C Compiler version zero dot two
            Current Settings
            ProPolice is currently disabled

[/usr/src]# gcc -fno-stack-protector -o fail1 fail.c

[usr/src]# gcc -fstack-protector -o fail2 fail.c

[/usr/src]# gcc -fstack-protector-all -o fail3 fail.c

[/usr/src]# ./fail1
        before foo()
        Segmentation fault

[/usr/src]# ./fail2
        before foo()
        Segmentation fault

[/usr/src]# ./fail3
        before foo()
        fail3: stack smashing attack in function fooAborted

>
> Im not too sure if grsecurity will guard against all that propolice will.
I
> should find different exploit examples perhaps. Try building the example
> exploits in libsafe's source, without propolice, and see if grsec aborts
> them...
>

When compiling the kernel with grsecurity patches, you can choose 1 of 4
security levels - low, medium, high and custom.  I chose high, which
installs PaX.  It appears from the log files that the PaX code is trapping
the buffer overflows.

I downloaded the libsafe source and built the exploits with propolice
disabled.  I then tested the exploits on a RedHat 9.0 kernel to verify that
they worked.  I then booted my HLFS kernel with gresecurity and tried the
exploits again.  In each instance, the exploit was aborted.  The exploits
tested were: t1, t1w, t3, t3w, t4, t4w, t5, t6, canary-exploit and
exploit-non-exec-stack.

Bill





More information about the hlfs-dev mailing list