Hi,
Past days I wrote about a regression test suite which i used to explain
why a grsecurity-like security improvement could be good for mainline
inclusion, and also, that at least the 50% of the faults it shows on
Vanilla sources could be solved without major blocking issues (aka big
deals, whatever else).
I've released the code, so, everybody could mess it up and send me
patches with fixes, enhancements, extra features or better source
comments ;)
The source code is available at
http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/collision-rts/.
An example results log dumped by it when running on a default Vanilla
kernel (no security patches, etc) can be found at:
http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/collision-rts/results/vanilla-2.6-default.log?rev=1.1.1.1&view=log
In the forthcoming days i will try to add more tests to it, mainly
related with capabilities and such, for SELinux and LSM testing.
Also, maybe an ExecShield specific test (see [1] and [2]) and possibly a
few other tests related with BSD Jails.
I would like to have feedback about it, but it's main goal is to show
that there are still some security "faults" that affect users of Vanilla
sources that can be solved without a lot of pain and could represent a
start for those who want better security worked on many time before me
and have been ignored or just left working alone and independently.
The suite has some tests related with "toolchain" hardening, but most
stuff is kernel-related.
Hopefully it will be useful, so, enjoy.
References:
[1]: http://212.130.50.194/papers/attack/ExploitingFedora.txt
[2]: http://phrack.org/phrack/56/p56-0x05
[3]: http://phrack.org/phrack/58/p58-0x04
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager
* Lorenzo Hern?ndez Garc?a-Hierro ([email protected]) wrote:
> Past days I wrote about a regression test suite which i used to explain
> why a grsecurity-like security improvement could be good for mainline
> inclusion, and also, that at least the 50% of the faults it shows on
> Vanilla sources could be solved without major blocking issues (aka big
> deals, whatever else).
Thanks, I'll take a look. Do you categorize the faults in any way?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
El mar, 18-01-2005 a las 15:04 -0800, Chris Wright escribi?:
> * Lorenzo Hern?ndez Garc?a-Hierro ([email protected]) wrote:
> > Past days I wrote about a regression test suite which i used to explain
> > why a grsecurity-like security improvement could be good for mainline
> > inclusion, and also, that at least the 50% of the faults it shows on
> > Vanilla sources could be solved without major blocking issues (aka big
> > deals, whatever else).
>
> Thanks, I'll take a look. Do you categorize the faults in any way?
There are separators to make sections of similar tests, but still not a
nifty "per-type" sections organization.
I would like to improve it and use percents and such instead of simple
"Vulnerable" and "Not vulnerable" results, so, you can have a global
idea of the current security status.
Patches are welcome, as I don't have a lot of time now (school "normal"
rhythm started this week).
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager
El mi?, 19-01-2005 a las 09:27 +0100, Arjan van de Ven escribi?:
> On Tue, 2005-01-18 at 23:55 +0100, Lorenzo Hern?ndez Garc?a-Hierro
> wrote:
> > Also, maybe an ExecShield specific test (see [1] and [2]) and possibly a
> > few other tests related with BSD Jails.
>
> > [1]: http://212.130.50.194/papers/attack/ExploitingFedora.txt
>
> fwiw this paper is about exploiting prelink more than execshield; the
> proposed technique only works because the system was prelinked (without
> prelink every time you start a program all addresses get randomized,
> with prelink the addresses randomize every 2 weeks) and the "security
> sensitive" application was not made a PIE.
Right, that's a point I forgot to talk about.
> The first makes it really hard to write generic exploits (but means you
> can do a local based attack within 2 weeks), the second means that the
> exploit technique only works for a subset of programs; in Fedora most
> (if not all) network daemons and a bunch of other things are PIE, and
> there even is an entire gentoo distribution which is entirely PIE.
Yes, the address space layout randomization (ASLR) as PaX calls it,
makes really difficult to get done the so-called ret2libc attacks, but
anyway it could be interesting to write some tests trying to achieve it,
most for fun than an useful thing, as (unexpected) results might be as
randomized as the address space can be ;D
PIE is, hopefully, also being introduced in Debian-based systems by the
Hardened Debian project.
Gentoo has the Hardened Gentoo official sub project, which is doing (and
has did) a great work around this stuff, among the deployment of other
security technologies.
Cheers and thanks for the comments,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]> [1024D/6F2B2DEC]
[2048g/9AE91A22] Hardened Debian head developer & project manager