lkml.org 
[lkml]   [2005]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
> still wrong. What you get this way is a nice, complicated NOP.

not only a nop but also a likely crash given that i didn't adjust
the declaration of some_function appropriately ;-). let's cater
for less complexity too with the following payload (of the 'many
other ways' kind):

[field1 and other locals replaced with shellcode]
[space to cover the locals of __libc_dlopen_mode()]
[fake EBX]
[fake ESI]
[fake EBP]
[address of field1 (shellcode)]
[address of user_input+x, ends with "libbeecrypt.so"]
[fake mode for __libc_dlopen_mode(), 0x01010101 will do]
[space for the local variables of __libc_dlopen_mode() and others]
[saved EBP replaced with address of [fake EBP]]
[saved EIP replaced with address of __libc_dlopen_mode()+3]
[user_input no longer used in the exploit]

user_input (the original, untouched buffer) ends with a suitable
library name (such as "libbeecrypt.so", see [1]). this string could
have also been left behind in the address space somewhere during
earlier interactions. we have to produce one 0 byte only hence
we're back at the generic single overflow case. this also no longer
relies on the user_input argument being at a particular address on
the stack, so it's a generic method in that regard as well.

one disadvantage of this approach is that now not only the
randomness in libc.so has to be found but also that of the stack
(repeating parts of the payload would help reduce it though), and
if user_input itself is on the heap (and there're no copies on the
stack), we'll need that randomness too.

in any case, you got your exploit method against latest Fedora (see
the attachment [2]), this should prove that paxtest does the right
thing when it exposes the weaknesses of Exec-Shield. now, will you
and Arjan do the right thing and apologize to us or do you still
maintain that paxtest is a sabotage?

[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132149
it also appears that not only the design and implementation of
PT_GNU_STACK are broken but its deployment as well. not even
its creators managed to get it right, what can we expect from
unsuspecting distros? 5 months and still no resolution? does
this backdoor really belong into linux?

[2] ESploit.c is a simple proof of concept self-exploiting test
that will hang itself when successful. compiler optimizations
and randomizations can introduce 0 bytes in some of the
addresses used (check shellcode length), play with them a bit
to get it to run. stack usage in the (ab)used libc functions
may also require adjusting the buffer sizes.

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

---- File information -----------
File: ESploit.c
Date: 8 Feb 2005, 0:07
Size: 1294 bytes.
Type: Program-source
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.071 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site