comp.lang.ada
 help / color / mirror / Atom feed
From: "Bob French" <bfrench2@cfl.rr.com>
Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits
Date: Thu, 17 Apr 2003 15:00:41 GMT
Date: 2003-04-17T15:00:41+00:00	[thread overview]
Message-ID: <tkzna.172914$o8.3337200@twister.tampabay.rr.com> (raw)
In-Reply-To: b7ka8l$bs6$1@slb6.atl.mindspring.net


"Brian Catlin" <brianc@sannas.org> wrote in message
news:b7ka8l$bs6$1@slb6.atl.mindspring.net...
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> 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





  reply	other threads:[~2003-04-17 15:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-16 16:54 Partial Hardware Protection for Buffer Overrun Exploits Warren W. Gay VE3WWG
2003-04-16 17:28 ` Vinzent Hoefler
2003-04-17 16:33   ` Warren W. Gay VE3WWG
2003-04-17 21:29   ` Robert A Duff
2003-04-16 19:13 ` Brian Catlin
2003-04-17 15:00   ` Bob French [this message]
2003-04-17 16:14   ` Warren W. Gay VE3WWG
2003-04-17 23:22     ` Randy Brukardt
2003-04-21 16:42       ` Warren W. Gay VE3WWG
2003-04-21 17:26         ` tmoran
2003-04-22  1:40           ` Frank J. Lhota
2003-04-22 21:15             ` Robert A Duff
2003-04-22 21:19               ` Ed Falis
2003-04-24  2:00                 ` Randy Brukardt
2003-04-24 13:49                   ` Ed Falis
2003-04-24 18:42                     ` Randy Brukardt
2003-04-24 18:49                       ` Ed Falis
2003-04-17 21:22 ` Robert A Duff
2003-04-21 16:33   ` Warren W. Gay VE3WWG
2003-04-21 19:28     ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox