[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

FW: Re: Unexecutable Stack / Buffer Overflow Exploits...


Sorry if this have been already discussed. I did not find it in the debian

This is a very good suggestion. 

- -----FW: <199912310054.TAA20402@tsx-prime.MIT.EDU>-----

Date: Thu, 30 Dec 1999 19:54:39 -0500
Sender: owner-linux-kernel@vger.rutgers.edu
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Steve VanDevender <stevev@efn.org>
Subject: Re: Unexecutable Stack / Buffer Overflow Exploits...
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, linux-kernel@vger.rutgers.edu

   From: Steve VanDevender <stevev@efn.org>
   Date: Thu, 30 Dec 1999 16:26:02 -0800 (PST)

   Many of the stack-smashing exploits I've seen pad the exploit
   code with a large number of no-op instructions; the return then
   has to point only somewhere into the no-op padding rather than
   directly at the useful part of the exploit code.  Making a
   successful exploit in those cases takes less detailed knowledge
   and a lot fewer attempts before finding a return address that
   works, and it works in many more cases since the frame that gets
   smashed can be located over a much larger range of addresses.

How much is a "large" number of no-op's?  4k?  8k?  Usually it's a lot
less than that; a few hundred no-op's at most.  Remember, you actually
have to send that many bytes down the network connection, and there may
be other things (such as the maximum UDP packet size) which may limit
how big you can make your "no-op runway".  

In any case, I suspect that if something randomly added some random
value between 0 and 128k to the stack pointer at startup time, it would
also go a fairly long way towards thwarting overrun attacks --- but make
no mistake, it's still only papering over the problem.

                                                - Ted

- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- --------------End of forwarded message-------------------------

- ----------------------------------
Anton R. Ivanov
IP Engineer Level3 Communications
RIPE: ARI2-RIPE      E-Mail: Anton Ivanov <aivanov@eu.level3.net>
@*** Dow's Law ***
      In a hierarchical organization, the higher,
      the greater the confusion.

- ----------------------------------
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org


Reply to: