public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: Paulo Marques <pmarques@grupopie.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
	linux-os@analogic.com,
	Linux kernel <linux-kernel@vger.kernel.org>,
	akpm@osdl.org
Subject: Re: Patch 4/6  randomize the stack pointer
Date: Fri, 28 Jan 2005 12:51:31 -0500	[thread overview]
Message-ID: <41FA7BA3.7010100@comcast.net> (raw)
In-Reply-To: <41FA74CA.2030303@grupopie.com>

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

  reply	other threads:[~2005-01-28 17:56 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-27 10:11 Patch 0/6 virtual address space randomisation Arjan van de Ven
2005-01-27 10:12 ` Patch 1/6 introduce sysctl Arjan van de Ven
2005-01-27 10:36   ` Andi Kleen
2005-01-27 11:13     ` Arjan van de Ven
2005-01-27 18:16   ` Pavel Machek
2005-01-27 19:11     ` Ingo Molnar
2005-01-27 19:46       ` Dave Jones
2005-01-27 19:53         ` Ingo Molnar
2005-01-27 19:53         ` Arjan van de Ven
2005-02-04 21:27   ` Benoit Boissinot
2005-01-27 10:12 ` Patch 2/6 introduce helper infrastructure Arjan van de Ven
2005-01-27 10:41   ` Andi Kleen
2005-01-27 11:58     ` Arjan van de Ven
2005-01-27 12:27       ` Andi Kleen
2005-01-27 12:43         ` Arjan van de Ven
2005-02-01 21:14   ` Matt Mackall
2005-01-27 10:12 ` Patch 3/6 per process flag Arjan van de Ven
2005-01-27 10:13 ` Patch 4/6 randomize the stack pointer Arjan van de Ven
2005-01-27 10:21   ` Christoph Hellwig
2005-01-27 17:38   ` John Richard Moser
2005-01-27 17:47     ` Arjan van de Ven
2005-01-27 18:04       ` John Richard Moser
2005-01-27 18:09         ` Arjan van de Ven
2005-01-27 18:12         ` Christoph Hellwig
2005-01-27 18:16         ` Linus Torvalds
2005-01-27 18:28           ` Linus Torvalds
2005-01-27 18:55             ` John Richard Moser
2005-01-27 18:49           ` John Richard Moser
2005-01-27 19:30             ` Linus Torvalds
2005-01-27 19:48               ` Arjan van de Ven
2005-01-27 19:59                 ` Linus Torvalds
2005-01-27 20:04                   ` Arjan van de Ven
2005-01-27 20:08               ` John Richard Moser
2005-01-27 19:19           ` linux-os
2005-01-27 19:52             ` Julien TINNES
2005-01-27 20:02             ` Arjan van de Ven
2005-01-27 20:13               ` John Richard Moser
2005-01-27 21:33                 ` jnf
2005-01-28 17:22                 ` Paulo Marques
2005-01-28 17:51                   ` John Richard Moser [this message]
2005-01-28 18:42                   ` Ingo Molnar
2005-01-29  6:04                     ` John Richard Moser
2005-01-27 20:37               ` linux-os
2005-01-27 20:45                 ` John Richard Moser
2005-01-27 21:39           ` John Richard Moser
2005-01-27 21:53             ` Arjan van de Ven
2005-01-27 22:34               ` John Richard Moser
2005-01-29  2:50                 ` Rik van Riel
2005-01-29  6:31                   ` John Richard Moser
2005-01-29  8:10                     ` Arjan van de Ven
     [not found]                       ` <41FBB821.3000403@comcast.net>
2005-01-29 16:42                         ` Arjan van de Ven
2005-01-29 16:59                           ` John Richard Moser
2005-01-29 16:46                         ` Arjan van de Ven
2005-01-29 17:04                           ` John Richard Moser
2005-01-29 17:37                     ` Jakub Jelinek
2005-01-29 17:49                       ` John Richard Moser
2005-01-29 17:55                         ` Christoph Hellwig
2005-01-29 18:10                           ` John Richard Moser
2005-01-29 18:12                             ` Rik van Riel
2005-01-29 18:16                             ` Christoph Hellwig
2005-01-29  7:46           ` John Richard Moser
2005-01-27 18:40         ` Felipe Alfaro Solana
2005-01-27 22:31     ` Jirka Kosina
2005-01-28  5:58       ` Ingo Molnar
2005-01-28 19:02         ` David Lang
2005-01-28  7:33       ` Arjan van de Ven
2005-01-27 19:43   ` Julien TINNES
2005-01-28  0:10     ` H. Peter Anvin
2005-01-28  0:23       ` Roland Dreier
2005-01-28  1:06         ` H. Peter Anvin
2005-01-28  2:03     ` Horst von Brand
2005-01-28  8:45       ` Julien TINNES
2005-01-27 20:23   ` Christoph Hellwig
2005-01-27 20:27     ` Arjan van de Ven
2005-01-27 20:32       ` Christoph Hellwig
2005-01-27 20:35         ` Arjan van de Ven
2005-01-27 20:40         ` Rik van Riel
2005-01-27 20:42           ` Christoph Hellwig
2005-01-27 20:56             ` Arjan van de Ven
2005-01-27 21:13               ` Linus Torvalds
2005-01-27 10:13 ` Patch 5/6 randomize mmap addresses Arjan van de Ven
2005-01-27 10:14 ` Patch 6/6 default enable randomisation for -mm Arjan van de Ven
2005-01-27 11:45 ` Patch 0/6 virtual address space randomisation Julien TINNES
2005-01-27 11:57   ` Arjan van de Ven
2005-01-27 17:42     ` John Richard Moser
2005-01-27 19:34       ` Julien TINNES
2005-01-27 19:57         ` John Richard Moser
2005-01-27 20:13         ` Arjan van de Ven
2005-01-28  8:45           ` David Weinehall
  -- strict thread matches above, loose matches on Subject: below --
2005-01-31 10:55 Patch 4/6 randomize the stack pointer linux
2005-01-31 17:28 ` John Richard Moser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41FA7BA3.7010100@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=pmarques@grupopie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox