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 X-Google-Attributes: gid115e50,public X-Google-Thread: 103376,63e8a95e8331225 X-Google-Attributes: gid103376,public X-Google-Thread: 102b75,dcf4be322bf26906,start X-Google-Attributes: gid102b75,public X-Google-ArrivalTime: 2003-04-21 09:48:13 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: <3EA41D43.9040802@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,comp.arch Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits References: <3E9D8AB6.4090009@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 21 Apr 2003 12:33:07 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1050942789 198.96.223.163 (Mon, 21 Apr 2003 12:33:09 EDT) NNTP-Posting-Date: Mon, 21 Apr 2003 12:33:09 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:36333 comp.arch:46756 Date: 2003-04-21T12:33:07-04:00 List-Id: Robert A Duff wrote: > "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've already acknowledged this fact, in an earlier post. > I also think you underestimate the danger of jumping into existing > read-only code. Whether or not I am "underestimating" is not important. I have however, already pointed out the danger of exploiting some existing "code" in the "read-only" region. But what point are you making here? Based upon your response, it seems to be something like "we shouldn't make any hardware change", to which, I have to disagree. > When it comes to security (as opposed to normal run-of-the-mill bugs), > the chain is only as strong as its weakest link. This part I agree with (at least in the long run). > So if you close 99% of > the holes, you don't prevent anywhere near 99% of the problems. Looking at the larger picture, I disagree slightly. Yes, in the long run, this will be the result if the issues are not all addressed. In the short term however, you _do_ eliminate an entire class of problems. This can be useful, for several reasons: i) to buy time, in order to address the other 1% ii) to make writing exploits so difficult, that the script kiddies won't bother any more (ie. fewer exploits are in the wild) iii) Some programs may not actually have that 1% vulnerability, and so they might represent a class of programs that can be trusted (ideal if this includes servers on the net side). iv) get people and CPU engineers thinking along this line to come up with other innovative solutions. For example, there's no reason that a jump to register instruction cannot be limited to text only code. > 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. I entirely disagree that this needs to "slow down" anything. If anything, a soft approach is slower(!). The CPU already must translate a virtual address (of any kind), and by the time the real address goes out to the cache and to memory, the information necessary for read-only (or not) is already known by the CPU. All it needs to do is test that flag (one entire bit, mind you ;-), and choose to accept the address or abort. > 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 Even better! Let's have Intel/AMD/IBM implement it in hardware. If people start asking for it, then maybe we'll actually get workable solutions. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg