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-ArrivalTime: 2003-04-17 09:29:42 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: <3E9ED2E7.80807@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: 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: Thu, 17 Apr 2003 12:14:31 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1050596071 198.96.223.163 (Thu, 17 Apr 2003 12:14:31 EDT) NNTP-Posting-Date: Thu, 17 Apr 2003 12:14:31 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:36237 Date: 2003-04-17T12:14:31-04:00 List-Id: Brian Catlin wrote: > "Warren W. Gay VE3WWG" wrote in message > news:3E9D8AB6.4090009@cogeco.ca... > >>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: > [snip] > > An excellent idea. Unisys implemented this 30 years ago in their 'A series' > machines; I can't say that I am familiar with this hardware, but I sense that you might misunderstand my suggested approach. I am _not_ suggesting in _this_ proposal that executed code must be in a read-only segment (text region), but that the new RETURN instruction only accept valid addresses in the read-only segments (ie. text region). I could be wrong, but I suspect that the hardware you speak of may insisted on a execute (or read-only) attribute, but this is very different. All buffer exploits that I know about, plant code in the stack frame (or perhaps even overrun the frame), and then pass control to that code by clobbering the return address that has been pushed on that stack frame. The return address should normally point to the code (text region), but in the exploit, it points to the stack frame (data region). Just insisting that the return instruction only accept a text region address, would largely eliminate the danger of running exploit code. > It seems to me, that the real root of the problem is the C language, and its > lack of a native string type (and the really crappy run-time library). While > these sorts of attacks probably aren't limited to C programs, I'd be willing to > bet that they are LOTS less prevalent in other languages. It also seems to me, > that programming has been made too easy; there are lots of people out there > writing software that should really be out cleaning toilets instead. > > -Brian While I agree that C (and other languages) do present a practical problem here, I don't see this as the "practical solution". Yes, it would be nice if UNIX/Linux/FreeBSD and Windows would all be rewritten in Ada95, and largely eliminate this problem. But do you really believe that this is going to happen any time soon? I can't even count on the name servers (bind) and dhcp servers and client programs to do this yet. If Intel provided an RETT (return to text) instruction, GCC could be enhanced to use it, and all of the existing Linux code base for example, could be strengthened a mere recompile. The only downside of this approach that I see, is that this might reduce the pressure for people to critically examine the issue (ie. move to Ada?) However, there is still the denial of service aspect, that this won't address anyway. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg