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

Re: PaX on Debian

Hash: SHA1

Steve Kemp wrote:
| 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.

Yeah I think on 3.3.4 on Gentoo has SSP

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

The binutils adds the header field needed for the PaX flags for paxctl.
~ This is important, because chpax uses an "unused" area in the header,
which is depricated.  Also, tools like strip will zero the chpax flags,
making them extremely volitile.

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

Firefox sets off SSP itself on load.

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

"Stack Smash Protection" is the new name of ProPolice?  o_o  Thought
that was the name of the concept.

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

Not sure.  I'm going by what I've been told by the Gentoo devs; I'm a
Hardened Gentoo user.

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

SELinux and SSP do two different things.  SSP prevents the program from
being exploited; SELinux contains the exploit.

PaX also aims to prevent the program from being exploited.

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

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.

Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


Reply to: