> I actually just tried to paxtest a fresh Fedora Core 3, unadultered,
> that I installed, and it FAILED every test. After a while, spender
> reminded me about PT_GNU_STACK. It failed everything but the Executable
> Stack test after execstack -c *. The randomization tests gave
> 13(heap-etexec), 16(heap-etdyn), 17(stack), and none for main exec
> (etexec,et_dyn) or shared library randomization.
because you ran prelink.
and you did not compile paxtest with -fPIE -pie to make it a PIE
executable.
>
> Also, before you say it, I read, comprehended, and anylized the source.
> This was PaXtest 0.9.6, and I did specific traces (after changing
> body.c to prevent it from forking) to look for mprotect() and mmap()
> calls and find out what they do (I saw probably glibc getting mmap()ed
> in, there wasn't anything in the source doing the mmap() calls I saw).
> There were no dirty tricks to mprotect() a high area of memory, which is
> something Ingo called foul on in 0.9.5.
there is one actually if you look careful enough.
>
> if (strlen(a) > 4)
> a[5] = '\0';
> foo(a);
>
> void foo(char *a) {
> char b[5];
> strcpy(b,a);
> }
>
> This code is safe, but you can't tell from looking at foo(). You don't
> get a look at every other object being compiled against this one that
> may call foo() either. So compile time buffer overflow detection is a
> best-effort at best.
actually this one gets caught, since this will be turned into a checking
strcpy which aborts after the 5th character.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
