Re: PaX on Debian (Recap 1)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll do a recapitulation of what has been covered thusfar in this
message. It's a long one, but it'll get us all on the same channel.
John Richard Moser wrote:
| I'm interested in discussing the viability of PaX on Debian. I'd like
| to discuss the changes to the base system that would be made, the costs
| in terms of overhead and compatibility, the gains in terms of security,
| and the mutability (elimination) of the costs.
|
| A PaX protected base system would be best compiled ET_DYN, which can be
| done by using modified spec files or a specially patched gcc to make
| pies-by-default binaries. Certain things don't compile this way; and
| thus would need this functionality disabled (modified spec, -fno-pic
| -nopie). This will be discussed in greater detail later.
|
Paragraph (2) was not discussed. Coverage of manipulating the gcc specs
file and ET_DYN adavtages and disadvantages should be discussed at some
point. This was touched on briefly for clarification in:
http://lists.debian.org/debian-security/2004/07/msg00177.html
But did not pan out.
| A PaX protected base would also benefit from Stack Smash Protection,
| which can be done via the gcc patch ProPolice. 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.
|
Paragraph (3) was touched on. The overhead of SSP has not been
discussed; but discussion of SSP in general has. See the end of this
post for details.
As for overhead, I'll put out that ProPolice/SSP is similar in
implementation to Immunix' StackGuard. StackGuard, to my understanding,
places the canaries in a slightly different place; but otherwise is the
same deal. It should thus have identical or near-identical results in a
benchmark.
Immunix did a benchmark, actually:
http://immunix.org/StackGuard/performance.html
PIE (Position Independent Executable) is said by some to have some kind
of performance hit on x86. I've never noticed it. It's not exactly
"essential" for PaX, but it is *HIGHLY* recommended, as it will reduce
potential false alarms (which entail PaX randomly killing things for no
real reason) and remove the overhead incurred by having ET_EXEC (which
need to be mapped at a constant base) executables mapped in a random
base (conflicts with previous statement, thus the overhead).
| 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.
|
Paragraph (4) was not discussed in great detail; kernel settings still
need to be looked over. I am prepared to deliver and discuss these when
needed.
| The costs in terms of overhead of PaX (on legacy x86 systems where it
| must emulate an NX bit) and ProPolice are both very minimal. With
| PAGEEXEC on hardware NX supported systems such as AMD64, there is no
| measurable overhead from PaX. ProPolice brings no significant overhead;
| measurements taken for StackGuard (a similar system which puts the
| canaries in a different place, but is otherwise identical) are available
| for this. This will be discussed in detail later.
|
Paragraph (5) has been covered. The cost in terms of overhead was
discussed in:
http://lists.debian.org/debian-security/2004/07/msg00174.html
It was found with weak confidence (i.e. the tests were not exhaustive,
100% reliable distributed benchmarks; but were reasonable) that SEGMEXEC
would pose <1% performance overhead on x86-based CPUs. SEGMEXEC does
noticably cut the address space in half.
PAGEEXEC is capable of supplying some ambiguous "minimal" overhead; but
it is possible for the speed-up that allows for this to be compromised,
which falls back to a variable overhead model to prevent a loss of
security, leaving us only able to say that PAGEEXEC is "unpredictable."
On HW NX supporting systems (such as AMD64 or PPC), overhead is 0 from
PAGEEXEC. The more general overhead from PaX (i.e. the extra kernel
code) is just a few extra checks and some randomization, and thus is not
at the moment predicted to be significant; at worst it is
computationally impossible for it to be greater than the total overhead
incurred from SEGMEXEC.
It is important to note that the benching tests were done with full PaX
vs PaXless. See the message referenced above for an outline of the test
performed.
| The costs in terms of compatibility with PaX and ProPolice are also
| minimal, and mutable. PaX breaks a handful of packages; but all of
| these can easily be marked via the chpax and/or paxctl tools to disable
| 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).
|
Paragraph (6) was covered partially in:
http://lists.debian.org/debian-security/2004/07/msg00174.html
It is noted that binaries can be marked to control protections of PaX.
It is also noted that I can supply a patch to PaX which allows the
SEGMEXEC/PAGEEXEC selection on boot-up on the kernel command line, in
case the limitations of SEGMEXEC (1.5GiB address space) on 32-bit CPUs
gets to be restricting.
It should have been covered that on 32 bit CPUs, if SEGMEXEC becomes
restricting, paxctl -Ps or chpax -Ps (depending on if it has
PT_PAX_FLAGS in its ELF header or not) can be used to force PAGEEXEC if
PAGEEXEC and SEGMEXEC are available, regardless of the default.
I also should have noted by now that the PaX patched kernels can be
compiled with PaX disabled, to provide a kernel-image for non-PaX
kernels. This would be a last-ditch effort which will work if there is
simply no other work-around for a given system; although paxctl/chpax
- -psemrx on the offending binaries does basically the same thing for
those alone.
Putting PaX in softmode on the kernel command line (pax_softmode=1) is
not sufficient, as poorly marked binaries (say -psE, which makes no
sense because -E isn't needed without -P or -S) will not be allowed to
run by PaX regardless of softmode.
ProPolice/SSP compatibility will need testing on the distribution side.
~ This is fairly simple to deal with: Package breaks, gcc
- -fno-stack-protector -fno-stack-protector-all . :) Avoid
- -fstack-protector-all unless you REALLY want to deal with things
breaking; I've heard that C++ especially dislikes -all, and haven't
heard since about it being fixed.
| Neither of these systems delivers a cost in terms of complexity of use
| to the user; these are both 100% transparent to the user. Added
| complexity in the form of configuring the PaX kernel; setting up the
| binary markings for packages that break; and disabling the gcc
| modifications for things that break are taken up by the distribution.
|
Paragraph (7) is a full explaination: Once the Debian devs have this in
place, the users don't need to give a half a damn.
| 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.
|
Paragraph (8) hasn't been discussed in technical detail; however, it's
sufficient to say that it doesn't really matter if you're willing to
take my word on this one. If you're interested, I can show controlled
theoretical situations where ProPolice/SSP is evasable.
PaX does not catch buffer overflows directly; thus, any attack stemming
from a buffer overflow but not triggering PaX is only going to be caught
by SSP.
| A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX
| and makes a good read for this. Likewise, one for Stack Smash
| Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to
| look over.
|
| 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.
|
Below are my final notes in recapitulation.
====1
It is also important for compatibility discussions to discuss the
message archived at:
http://lists.debian.org/debian-security/2004/07/msg00105.html
regarding binutils with PaX and SSP. This is a pretty short topic,
which I'll outline here.
It doesn't hurt to have the PaX binutils patch (which supplies the
PT_PAX_FLAGS header field) on PaX or non-PaX systems; the kernel will
load either type with or without PaX in the kernel. Thus, if Debian is
going to supply and support a PaX system with binaries marked as
appropriate for PaX, the default binutils should be a PaX patched one.
If Debian is also going to support SSP, then SSP must also be patched
in. As I understand it, this will have no effect for binaries compiled
- -fno-stack-protector.
Both patches would be included in the default version of binutils in the
ideal security situation of PaX+SSP combination.
====2
The issue of 'mudflap' was touched on in:
http://lists.debian.org/debian-security/2004/07/msg00175.html
It was responded to in:
http://lists.debian.org/debian-security/2004/07/msg00180.html
This response referenced another message at:
http://lists.debian.org/debian-devel/2004/07/msg01154.html
This message indicates that mudflap is not suitable as a security tool,
because of its excessive performance impact. ProPolice/SSP should be
ported to 3.5 when 3.5 is around, and I've heard that nothing in
'mudflap' should really interfere with the smooth operation of SSP.
====3
The issue of trying to patch Debian's kernel-image sources with PaX was
discussed in:
http://lists.debian.org/debian-security/2004/07/msg00179.html
Note that I am not advocating a "kernel-patch-2.6.7-pax" package; but
rather, a modification of the base system and a "kernel-image-2.6.7"
with PaX as well as a "kernel-image-2.6.7-nopax" with PaX disabled. My
aims are for Debian to supply the most secure base possible without
being invasive in terms of overhead, compatibility, or end-user complexity.
I expect you may instead have "kernel-image-2.6.7-pax" with PaX enabled,
and "kernel-image-2.6.7" with it disabled, as an introductory test.
This is fine; but both may indeed be worked off the same tree, with the
PaX patch applied.
| --John
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBZKuhDd4aOud5P8RAmZEAJ9WIqjuOeRgXPayC/3fCDVOu3v3BACfdcQB
0RT+u2WXMkXK8+XTYPQiFvQ=
=Fd7I
-----END PGP SIGNATURE-----
Reply to: