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-ArrivalTime: 2003-04-16 10:29:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!firewall.mdc-dayton.COM!not-for-mail From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits Date: Wed, 16 Apr 2003 13:28:50 -0400 Organization: JeLlyFish software Message-ID: References: <3E9D8AB6.4090009@cogeco.ca> NNTP-Posting-Host: firewall.mdc-dayton.com (12.161.103.180) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: fu-berlin.de 1050514142 1910110 12.161.103.180 (16 [175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:36195 Date: 2003-04-16T13:28:50-04:00 List-Id: "Warren W. Gay VE3WWG" wrote: >If it is possible for the CPU to distinguish between the >"text" region and the "data" regions (including stack), It does in some way. But in the flat model it does not distinguish the addresses. So if you say CS:[03FC7687] and SS:[03FC7687] it refers to the same memory, although the access rights are different depending on how you access it. That is the danger. >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). There is already an easier solution (at least for x86-CPU's): Don't use a purely flat model, with this I mean, you shouldn't use the same address space for both data/stack and code. This could already be accomplished with the standard protection/paging features of the x86. Unfortunately there are some features in current real world compilers (like for instance, the so-called trampolines) that require an "executable" stack segment. Simply get rid of these features and the solution is easy. Well, it would make the writing of self-modifying code a little bit harder. >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. Because you cannot write to the code segment without triggering a GPF it would be simply impossible. Still, you could launch a DoS-attack this way. >There has to be a better solution to the current crop of >buffer exploits, that are being used daily. Yes. What about using Ada? ;-) Vinzent. --=20 Parents strongly cautioned -- this posting is intended for mature audiences over 18. It may contain some material that many parents would not find suitable for children and may include intense violence, sexual situations, coarse language and suggestive dialogue.