[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PaX on Debian

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).


> 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:


  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!

# The Debian Security Audit Project.

Attachment: pgp5KVAiz59wL.pgp
Description: PGP signature

Reply to: