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-16 12:17:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!newspump.monmouth.com!newspeer.monmouth.com!beamish.news.atl.earthlink.net!guinness.news.atl.earthlink.net!news.atl.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Brian Catlin" Newsgroups: comp.lang.ada,comp.os.assembly Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits Date: Wed, 16 Apr 2003 12:13:29 -0700 Organization: Sannas Consulting Message-ID: References: <3E9D8AB6.4090009@cogeco.ca> NNTP-Posting-Host: 44.a4.37.b8 X-Server-Date: 16 Apr 2003 19:17:41 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Xref: archiver1.google.com comp.lang.ada:36202 Date: 2003-04-16T19:17:41+00:00 List-Id: "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; however, getting this to work on a more conventional processor architecture (the Unisys machines are stack-based, and no assembler is sold for them, just high-level languages) would be rather difficult, I suspect. The beauty of allocating space on the stack for strings, is when the routine returns, the storage is automatically returned. A software-only solution could be implemented purely in the compiler, by allocating the string storage on the heap (with guard pages around it), and then deallocating everything when the routine returns. This would impact performance, but would also make the system less vulnerable to this particular attack. 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