From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 115e50,63e8a95e8331225,start X-Google-Attributes: gid115e50,public X-Google-Thread: 103376,63e8a95e8331225,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-16 10:09:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3E9D8AB6.4090009@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.os.assembly Subject: Partial Hardware Protection for Buffer Overrun Exploits Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 Apr 2003 12:54:14 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1050512054 198.96.223.163 (Wed, 16 Apr 2003 12:54:14 EDT) NNTP-Posting-Date: Wed, 16 Apr 2003 12:54:14 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:36194 Date: 2003-04-16T12:54:14-04:00 List-Id: I am curious if anyone has discussed this idea before: REVIEW: Buffer exploits work of course, by allowing the attacker to overwrite a buffer (array) with hacker code to be executed. Part of this exploit includes the necessity of overwriting the return address on the _stack_ frame, that the current function will use when it exits (opcode RET? My assembly knowledge is admitedly (for Intel) is very rusty). The RET instruction is how control is being given to planted "hacker code". Obviously, this is _not_ what we want happening on Internet exposed machines. SUGGESTED HARDWARE SOLUTION: For UNIX/Linux anyway (and I think for Win32 also), the code is in protected segments that are at least "read only" and on some platforms perhaps even marked "executable". In UNIX terms, this represents the "text" area of an executable. This means that _normally_, the return address should only refer to text region addresses.... (or alternatively, "read-only" regions of virtual memory). If it is possible for the CPU to distinguish between the "text" region and the "data" regions (including stack), then a new instruction (say RETT - Return to Text), could cause a fault to occur, if the return address is not to a text virtual memory address (for exploits this address points to a "data" region, and usually part of the current stack frame). Then GCC could be enhanced to replace the dangerous RET instruction with the safer RETT (say) instruction, and one large class of exploits would be foiled in newly compiled code. This does not of course fix the denial of service problems with overruning buffers, but that is another matter. At least we eliminate the ability of the attacker to execute planted code. As far as I see, the only way to exploit buffers would then require the attacker to find usable sections of text to do his bidding. I suspect that this would make the attack considerably more difficult, and perhaps in many cases, impossible or not worth pursuing. YOUR FEEBACK? Has this been discussed before? Is Intel listening? There has to be a better solution to the current crop of buffer exploits, that are being used daily. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg