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

Peter Busser
2005-02-01T09:45:07Z

On Monday 31 January 2005 17:41, you wrote:
> 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)
> ok the paxtest 0.9.5 I downloaded from a security site (not yours) had
> this gem in:

So what does 0.9.5 have to do with 0.9.6?

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

Ah, so you are saying that I sabotaged PaXtest? Sorry to burst your bubble,
but the PaXtest tests are no real attacks. They are *simulated* attacks. The
do_mprotect() is there to *simulate* behaviour people found in GLIBC under
certain circumstances. In other words: This is how certain applications
behave when run on exec-shield. They complained that PaXtest showed
inaccurate results on exec-shield. Since the purpose of PaXtest is to show
accurate results, the lack thereof has been fixed.

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

Again, this is a *simulation* of the way real-life applications could interact
with the underlying system. Again people complained that the results shown
were not accurate. And that has been fixed.

I am well aware of complaints by some people about this behaviour. That is why
there is a separated kiddie and blackhat mode in the latest PaXtest version.
The kiddie mode is for those people who prefer to feel warm and cozy and the
blackhat mode is for those who want to find out what the worst-case behaviour
is. So if you don't like the blackhat results, don't run that test!

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

No, these things are also in the officially released sources. I put them in
myself in fact.

Interesting. So you are saying that even though applications sometimes use
mprotect(), either directly or indirectly through GLIBC (such as
multithreaded applications), and there are applications in the wild which use
nested functions, that PaXtest should not use these to simulate those kinds
of applications. Well, that is an opinion. A strange opinion. Does that mean
you ``desabotage'' all other applications on this planet as well? Or is
PaXtest perhaps special, because it tells people what really goes on?

My opinion is that PaXtest is correctly showing the consequences of the design
decisions you and other people who hacked exec-shield made. These
consequences are nowhere documented. So PaXtest is the only source for people
to find out about them. It seems to me that you would rather not have people
find out about it. It looks like you would rather prefer to cowardly kill the
messenger than to stand up for the design decisions you made, like a real man
would.

If that is the kind of person who you really are, then you have just managed
to disappoint me. If you'd knew me, you'd know that that is quite an
accomplishment. And frankly speaking, I don't think I would be happy with
this if I were your employer. Since this kind of negative behaviour also
reflects on the company you represent.

Anyways, I now know enough about this and I'm done wasting my time on this
childish discussion. If you, or anyone else for that matter, has complaints
about PaXtest or patches to improve it, please let me know. Otherwise I
suggest to leave me alone and to try to pick someone half your size to bully
around next time.

Groetjes,
Peter.