[lkml]   [2005]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Patch 4/6 randomize the stack pointer

> 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

> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [W:0.081 / U:1.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site