lkml.org 
[lkml]   [2005]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patch 4/6 randomize the stack pointer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Paulo Marques wrote:
> John Richard Moser wrote:
>
>> In other words, no :)
>>
>> Here's self-exploiting code to discover its own return address offset
>> and exploit itself. It'll lend some insight into how this stuff works.
>
>
> I really shouldn't feed the trolls, but this must be the most silly
> piece of code I saw on this mailing list in a very long time (and there
> have been some good examples over time).
>
> The stack randomization doesn't prevent some sort of attacks (like
> return into libc, etc.) and given a small randomization it might be
> possible to write an exploit with a long sequence of NOP's and a return
> address somewhere in there (the attacker wouldn't know exactly where,
> but it wouldn't matter anyway). If we are able to write 'N' NOP's then
> we get a 'N'/64k chance that the exploit works.

And the stack is a few megs, so you can write 64k of NOPs. ;)

>
> Your code doesn't show any of this kinds of attacks. It just shows that
> if you're able to run code then.... you're able to run code?
>

The guy wanted to know how buffer overflows worked, so I showed him a
self-exploiting buffer overflow. He didn't come in saying "I've got 500
years of experience writing buffer overflows, how would this stop it?"

It at least shows a buffer of length X overflowing into the return
pointer and changing it to address A of another function. That's all I
wanted to do.

Interestingly enough, I used this code in real life for a test for the
IBM Stack Smash Protector. It made a neat regression test. The code
overflows into the return pointer and sets it to payload() 100% of the
time, even in the presence of NX protection and full ASLR (PaX' 256M or
(amd64) 64GiB, this 64k, or the HT 8k). It DOES trigger SSP, which
halts the payload.

> What are you going to show next? That you can steal your own car? Are
> you going to blame the car manufacturer's for that?
>

No, though it'd be interesting to show my car stealing itself :)

> As it was already pointed out this is a step into implementing a larger
> randomization, so that things don't break all at once. Even a large
> stack randomization is just another layer of protection, as there are
> still attacks that it doesn't prevent.... Duh.
>
>> [...] /*find the distance between a and myret*/
>> for (i = (void*)a; *(void**)i != myret; i++) {
>> distance++;
>> }
>
>
> And this must be "la piece de resistance". Some very obfuscated (and
> inefficient) way to do a simple unsigned subtraction...
>

Yeah, but I hate warnings. It works without all the fancy casting, but
the compiler is like "OMFG WARNING WARNING DANGER WILL ROBINSON
ARITHMETIC ON POINTERS DR SMITH WANTS TO MOLEST YOU WARNING WARNING"

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+nujhDd4aOud5P8RAtc+AJ9t2EaQWQujOe3fyf/vg4jzUK9/TQCeMzBJ
Cjn/NUFS9+oxPJnU3u4XAsE=
=Vc2s
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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