Re: PaX on Debian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steve Kemp wrote:
| On Sun, Jul 25, 2004 at 02:26:15PM -0400, John Richard Moser wrote:
|
|
|>| 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
|
|
| It does.
|
|
|>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.
|
|
| Shouldn't strip be updated to ignore this 'unused' field, or
| would it be more sensible to set aside a real area for the flag?
Read again
"The binutils adds the header field needed for the PaX flags for paxctl"
| ELF
| is simple to update with new sections and maybe adding support for
| the runtime loader/linker would be more future proof..
|
|
|>| 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.
|
|
| When you say 'sets of' do you mean disable? I find that unlikely,
| as it's not the kind of thing that can be disabled when all the
| canary checking code is incorporated into the binary...
|
I mean firefox DIES due to a segfault. SSP segfaults when it detects an
overflow.
If you know something we don't, I think the Hardened Gentoo team would
like to know
|
|>"Stack Smash Protection" is the new name of ProPolice? o_o Thought
|>that was the name of the concept.
|
|
| SSP is the name for one implementation of stack smashing protection
| which was previously known as ProPolice.
| It's available from IBM at the following URL:
|
| http://www.trl.ibm.com/projects/security/ssp/
|
:)
|
|>| 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.
|
|
| But interested in Debian?
|
I'm interested in getting transparent (i.e. no extra passwords, no extra
user configuration, no extra user hassle) security enhancements like PaX
and SSP into the base distributions of regular Linux distros, as I
believe they are appropriate for machines not operating in a secure
environment. I've went at Mandrake and SuSE too, but they ignore me.
Machines in a secure environment will be interested in Adamantix or full
Hardened Gentoo, or whatever Red Hat Enterprise Server or whatever it's
called that has 10000 security features comes out. This is because they
will host sensitive data, and probably be faced with more direct attacks.
Machines *NOT* in a secure environment, however, will benefit from the
simpler, transparent subset of features that a secure system provides.
They won't be up for containing a security breach; but they'll be safely
protected from any weird Sasser or MSBlast type worms and other annoyances.
As it stands now, every little security hole in MS RPC or other system
services on Windows needs a patch to fix it. Before these patches come
out, millions of machines get infected with worms that use the security
holes to get into the machines.
Linux is not immune; if we had 98% of the market share, every little
hole in everything would result in millions of desktop users getting
flooded with these things too. There's no harm in BLOCKING THIS CRAP
from ever happening. It's not going to bug the users with 5000 extra
passwords, it's not going to require a USB stick with an RSA key on it
to boot, and it's not going to eat up 50% of your CPU's processing power.
Furthermore, using these systems NOW will bring them further into the
field, exposing more attacks that get around them. There is no security
in obscurity; we're simply faced with what we can and can't stop, and
from this we fix things so we CAN stop them, or we tell everyone when
there's a SEVERE security issue that we can't deflect.
|
|>SELinux and SSP do two different things. SSP prevents the program from
|>being exploited; SELinux contains the exploit.
|
|
| That's a simplistic explaination .. but it's not too far from
| the truth ;)
|
Hey. Simple is good.
|
|>PaX also aims to prevent the program from being exploited.
|
|
| The randomization is an interesting technique and it seems
| sufficiently simple concept that it would be interesting to
| see how well it works.
|
Did you read the wikipedia article and the docs? :P
The restriction of mprotect() is also an interesting technique, as it
lets you force programs to listen to you. In fact, I've had issues with
things like Flash and Java plug-ins demanding an executable stack, and
I've simply used execstack -c to turn that off. PaX can emulate
trampolines, which is why the executable stack is needed in the first
place; and these libraries DON'T actually have trampolines in them, so I
don't even need emutramp enabled without an executable stack. It seems
that alsalib did need emutramp (so I disabled the executable stack and
enabled emutramp); but that's going to be fixed soon.
An executable stack is a quick way to make your programs 100%
exploitable; there's no protection offered once the stack is PROT_EXEC.
The randomization is more of a probabilistic approach than a guarantee.
~ You'll probably want to combine it with the obscurity patch:
http://cr0.org/pax-obscure/
It also breaks wine in a probablistic percentage of the time :) The
devs of Wine have gotten around this: Make sure to paxctl -x the wine
binary, and its preloader will load the .exe before other libs are
mmap()ed in. They're great people.
| Steve
| --
- --
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
iD8DBQFBBDeehDd4aOud5P8RAsywAKCOivQMWl7f2d3K1DhUD+MbUZmLYgCZAbWP
u0VahfMo6HEnoSAVKXbhV/U=
=TDQd
-----END PGP SIGNATURE-----
Reply to: