C considered harmful: was Debian attacker may have used new exploit

[Tim Writer]

Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> writes:

> On Wed, 2003-12-03 at 22:55, Peter Hiscocks wrote:
> > OK, I hate to flog a dead horse but really:
> > 
> 
> Hmmmm, this is likely to start a looooong drawn out flame thread. 
> Language arguments almost always do.  So, with trying to prevent that in
> mind, I will avoid standing up for my general language of choice and
> instead offer an alternative.
> 
> > This exploit, like others against Unix machines many years ago, was based on
> > a buffer overflow dumping the user into supervisor space. This, in turn, is
> > a direct result of the fact that the C programming language does not check
> > or enforce limits on a string length or buffer size - that's left up to the
> > individual programmer.
> > 
> > Surely, given the importance of security, it should be possible to fix the C
> > language (or my preference, use a different one) to do systems programming.
> > After all, C is not so much a systems programming language as a high-level
> > version of assembly language.
> > 
> 
> "Fixing" C in the sense you're imagining will never happen and people
> often do use other languages for specific tasks.  However, other
> languages are not immune to buffer overflows as most of them are
> actually written in C themselves.

Not immune but still resistant.  Typical C programs are full of calls to
"dangerous" functions like strcpy() and sprintf(), as well as direct pointer
manipulations.  While language interpreters are no different, their cores
tend to be quite small compared with modern behemoths and are well tested
both with comprehensive test suites, which accompany most decent languages,
and via applications written in the language.

The flip side of course is that a buffer overflow (or similar problem) in a
language implementation has the potential to affect all applications deployed
in that language, so the impact could be much more widespread than a buffer
overflow in a given C application.

> The better solution is things like stackguard[1] and execshield[2] which
> actually fix the root problem: the stack should NOT be executable and
> neither should most of the heap and likewise portions of memory which
> are actively executable shouldn't be writable from userspace.

Maybe.  Some language environments rely on an executable stack to implement
trampolines.  An executable heap could be useful in languages with
just-in-time compilation or dynamic loading of compiled code, although I
don't know if any language implementations use such techniques.

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
905.771.0017 ext. 225                           thornhill, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml