On Sun, Jul 25, 2004 at 12:57:29PM -0400, John Richard Moser wrote: > A PaX protected base would also benefit from Stack Smash Protection, > which can be done via the gcc patch ProPolice. I have been flirting with SSP for months now, but the most recent patches included with GCC do not apply cleanly. Watch for a bug against GCC shortly with updated SSP patches. > This imposes minimal overhead, which will be discussed in > greater detail later. It overlaps and extends many of the protections > PaX offers, but catches earlier on; and is thus a good system to pair > with PaX. I've not looked at the combination, but there is already a patched binutils for PaX available unofficially for unstable, and I have gcc patched with SSP (lags behind unstable releases - currently a little out of date due to the breakages recently). http://people.debian.org/~skx/ssp.html > PaX is a kernel level patch, so certain kernel settings would be needed. > ~ Some of the settings available in PaX are high-overhead or break > things in a way which cannot be worked around, and should thus be off. > These will be discussed later. SSP is remarkably simple to apply and works with all packages I've been able to test on x86. > The costs in terms of compatibility with PaX and ProPolice are also Probably less confusing to all if you refer to ProPolice by its new name, SSP, exclusively. > the protections that break them. ProPolice is set off by some programs > (firefox for one), which simply must be compiled without ProPolice > (-fno-stack-protector -fno-stack-protector-all). I've not noticed this - Mozilla certainly seems fine with SSP compilers. I've been using it on my own unstable boxes for some time. What, specifically, breaks? > Both of these systems bring a significant security gain. ProPolice > prevents buffer overflow attacks, turning them into program crashes (DoS > attacks). Some buffer overflows, especially for buffers in structures > adjacent to function pointers or other pointers, can escape the > ProPolice logic, however; thus PaX is also needed. This will be > explained in greater detail later. I've keep a running log of all the security holes I've discovered, and more recently those by other members and a note as to whether SSP protects against them. This is available here: http://shellcode.org/Advisories/ As you can see many, but not all, attacks are protected against with SSP. SELinux would almost certainly do better ... (Because the things that aren't protected against are failure to drop privileges when using popen/system - SELinux could protect against this, SSP cannot). > Please reply and cite specific concepts you would like to discuss > further. I would rather not write up a 10 page paper by explaining all > of these at once; but if demanded, I'll do just that. Be ready to > swallow a large pill though. Looking forward to it already! Steve -- # The Debian Security Audit Project. http://www.debian.org/security/audit
Attachment:
pgpvzOPO6Lb_x.pgp
Description: PGP signature