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: 102b75,dcf4be322bf26906 X-Google-Attributes: gid102b75,public 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-21 12:28:53 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsgate.duke.edu!newsfeed!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada,comp.os.assembly,comp.arch Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits Date: 21 Apr 2003 15:28:46 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <3E9D8AB6.4090009@cogeco.ca> <3EA41D43.9040802@cogeco.ca> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1050953332 15164 199.172.62.241 (21 Apr 2003 19:28:52 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 21 Apr 2003 19:28:52 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:36338 comp.arch:46762 Date: 2003-04-21T15:28:46-04:00 List-Id: "Warren W. Gay VE3WWG" writes: > I've already acknowledged this fact, in an earlier post. True. But you didn't acknowledge the consequence given the "weakest link in chain" issue. > > 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? I was trying to make the "weakest link in chain" point. > Based upon your response, it seems to be something like "we > shouldn't make any hardware change", to which, I have to > disagree. Well, "we" as in "you and me" aren't making any changes to the Intel hardware architecture, as far as I know. ;-) But, yes, I'm saying there's no point in making hardware changes that will fix only part of the problem. I admit that my opinion might be colored by a "purist" attitude: the "right" solution is array bounds checking done in software. > > 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). OK. But note that hardware changes are necessarily "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% Shrug. > ii) to make writing exploits so difficult, that the script > kiddies won't bother any more (ie. fewer exploits are > in the wild) I don't know much about "script kiddies", but I was under the impression that they can bring sophisticated technology to bear, via scripts, even if they don't understand much. > 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). Well, if you mean programs that don't need write access to executable memory, then I agree there's a reasonable class of such programs. If you mean programs that don't do indirect jumps/calls, then no. > 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. Yeah, I guess you're right on this point. What you need is protection bits that express executable-but-not-writeable, and corresponding OS support. But I still say, the "chain links" thing is important. One must at least address all indirect jumps, not just return instructions. - Bob