Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stackpointer)

[Arjan van de Ven]

On Mon, 2005-01-31 at 13:57 +0100, Peter Busser wrote:
> Hi!
> 
> > I'm not entirely happy yet (it shows a bug in mmap randomisation) but
> > it's way better than what you get in your tests (this is the
> > desabotaged
> > 0.9.6 version fwiw)
> 
> As you may or may not know, I am the author of PaXtest. Please tell me what a 
> ``desabotaged'' version of PaXtest exactly is. I've never seen a 
> ``sabotaged'' PaXtest and I'm interested in finding out who sabotaged it and 
> for what purpose.
> 
> Come to thin

> I'm sorry to have to bother the people on this list, as you have much more 
> important things to do. But for me personally, the integrity of PaXtest (and 
> related to that, my personal integrity) matters a great deal. So I'd like to 
> get to the bottom of this, even if that means bothering lkml. I hope Arjan 
> can provide facts soon, so I can take action against this sabotage. 

ok the paxtest 0.9.5 I downloaded from a security site (not yours) had
this gem in:

--- paxtest/body.c
+++ paxtest-0.9.5/body.c        2005-01-18 17:30:11.000000000 +0100
@@ -29,7 +29,6 @@
        fflush( stdout );

        if( fork() == 0 ) {
+               do_mprotect((unsigned long)argv & ~4095U, 4096,
PROT_READ|PROT_WRITE|PROT_EXEC);
                doit();
        } else {
                wait( &status );

which is clearly there to sabotage any segmentation based approach (eg
execshield and openwall etc); it cannot have any other possible use or
meaning.

the paxtest 0.9.6 that John Moser mailed to this list had this gem in
it:
@@ -39,8 +42,6 @@
         */
        int paxtest_mode = 1;

+       /* Dummy nested function */
+       void dummy(void) {}

        mode = getenv( "PAXTEST_MODE" );
        if( mode == NULL ) {


which is clearly there with the only possible function of sabotaging the
automatic PT_GNU_STACK setting by the toolchain (which btw is not fedora
specific but happens by all new enough (3.3 or later) gcc compilers on
all distros) since that requires an executable stack.

Now I know you're a honest and well meaning guy and didn't put those
sabotages in, and I did indeed not get paxtests from your site directly,
so they obviously must have been tampered with, hence me calling it de-
sabotaging when I fixed this issue (by moving the function to not be
nested).

Greetings,
   Arjan van de Ven

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/