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-17 08:00:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed-east.nntpserver.com!nntpserver.com!news-west.rr.com!cyclone.tampabay.rr.com!news-post.tampabay.rr.com!twister.tampabay.rr.com.POSTED!53ab2750!not-for-mail From: "Bob French" Newsgroups: comp.lang.ada References: <3E9D8AB6.4090009@cogeco.ca> Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: Date: Thu, 17 Apr 2003 15:00:41 GMT NNTP-Posting-Host: 65.33.98.194 X-Complaints-To: abuse@rr.com X-Trace: twister.tampabay.rr.com 1050591641 65.33.98.194 (Thu, 17 Apr 2003 11:00:41 EDT) NNTP-Posting-Date: Thu, 17 Apr 2003 11:00:41 EDT Organization: RoadRunner - Central Florida Xref: archiver1.google.com comp.lang.ada:36235 Date: 2003-04-17T15:00:41+00:00 List-Id: "Brian Catlin" wrote in message news:b7ka8l$bs6$1@slb6.atl.mindspring.net... > "Warren W. Gay VE3WWG" wrote in message > news:3E9D8AB6.4090009@cogeco.ca... > > I am curious if anyone has discussed this idea before: > > > [snip] > > 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 The problem isn't really the string type. In C parameters for a subroutine get pushed on the stack. Must have read/write access. The call instruction pushes the return address. Must have read/write access. In the beginning of the subroutine initialized local variables get pushed on the stack and uninitialized variables have space allocated by moving the stack pointer according to their size. Must have read/write access. Either string or array or struct missapplied can step on that return address stored right in the middle of read/write data. The stack has other return addresses to caller of the caller, etc. The data on the stack can also contain a pointer to code. A sort routine can be passed the address of the routines that compare a pair of items and swap a pair of items. It isn't just return addresses that can be problems. The call instruction in the write protected TEXT segment is safe. The real problem is that programmers fail to check necessary limits. That isn't to say that the checking is trivial. If a string space (array of chars) is allocated on the stack and passed to a subroutine there needs to be a limit passed, or a constant limit, and the limit must be less than or equal to the size of the array as allocated by all callers. > 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. Languages that allow the use of a pointer to memory have the issue. Intel x86 got the bounds checking instruction back in the days of 80186 but the subroutine may not know the size of the buffer it is working with. It seems that information hiding happens. > 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 > > Bob