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: 103376,63e8a95e8331225 X-Google-Attributes: gid103376,public X-Google-Thread: 115e50,63e8a95e8331225 X-Google-Attributes: gid115e50,public X-Google-ArrivalTime: 2003-04-17 14:22:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!arclight.uoregon.edu!newsfeed!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada,comp.os.assembly Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits Date: 17 Apr 2003 17:22:04 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <3E9D8AB6.4090009@cogeco.ca> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1050614526 8186 199.172.62.241 (17 Apr 2003 21:22:06 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 17 Apr 2003 21:22:06 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:36252 Date: 2003-04-17T17:22:04-04:00 List-Id: "Warren W. Gay VE3WWG" writes: > 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. Overwriting the return address is probably the easiest way to gain control, but there are lots of other writeable locations containing addresses that will be jumped to, so the RET/RETT instruction is not the only problem. I also think you underestimate the danger of jumping into existing read-only code. When it comes to security (as opposed to normal run-of-the-mill bugs), the chain is only as strong as its weakest link. So if you close 99% of the holes, you don't prevent anywhere near 99% of the problems. It's a RISC vs CISC thing. The RISC approach is to do bounds-checking in software, and this has been well understood for decades (since before RISC was invented). So it's pretty annoying to have a hardware-based solution, which slows down all returns (and all indirect jumps and calls, I would claim) just because the industry is unwilling or unable to use reasonable programming languages. Your question is really a hardware architecture issue, so you might want to post it to comp.arch. In fact, I think if you search the archives, you'll find similar ideas proposed there. - Bob