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

[Marcus Brubaker]

On Wed, 2003-12-03 at 23:30, Henry Spencer wrote:
> On Wed, 3 Dec 2003, Peter Hiscocks wrote:
> > This exploit, like others against Unix machines many years ago, was based on
> > a buffer overflow dumping the user into supervisor space.
> 
> Actually, no, as I understand it (with the caveat that I haven't really
> gone investigating), this one is *not* a buffer overflow, exactly.  It's
> the result of *integer* overflow in (essentially) a buffer-overflow check. 
> A language with automatic buffer-overflow checks could easily have the
> same vulnerability, if the implementor wasn't careful. 
> 

Interesting, this is certainly a less common form of exploit...

> > After all, C is not so much a systems programming language as a high-level
> > version of assembly language.
> 
> Oddly enough, it has pushed most "real" systems programming languages out
> of the business.  And this is *not* because of sharp marketing tactics or
> firm backing by a big organization or dot-com hype -- quite the contrary. 
> It succeeded because people with work to do find it easier to get results
> in C than in "real" systems programming languages, and so it spread and
> prospered despite inept or nonexistent marketing, uncertain support, and a
> marked dearth of hype. 
> 
> It behooves people who aspire to design systems programming languages to
> *PAY* *ATTENTION* *DAMMIT*, rather than just casting aspersions on the
> intelligence and judgement of the customer.  It is their own damn fault;
> their languages keep failing, and C keeps succeeding despite its nasty
> flaws, because they keep ignoring the needs of the real language users. 
> People went with C because it did what they wanted, instead of telling
> them they shouldn't want that.
> 

Honestly, I don't think there will be a language to supplant C as a
*systems* programming language in general any time soon.  Frankly,
systems programming too frequently requires breaking the rules that
other languages commonly enforce.  There have been a lot of great
languages developed out there for specific tasks.  Perl is gorgeous for
text processing, as is python I've heard.  BASH is fair for simple task
automation, and tolerable for slightly more complicated tasks.  Matlab
is a GODSEND for anyone doing algorithm prototyping and other kinds of
scientific computation.  Java is worlds beyond C++ when it comes to
OOP.  Hell, even Prolog and the many species of LISP-type-languages are
interesting in their own right (though not terribly useful in my mind).

The point though is that for applications where you need the kind of
flexibility (or rope...heh) that C offers, there has yet to be any good
substitutes.  But if you fit well into a specific category of
application development then there is a whole host of better choices for
you.  For instance, next major GUI application I write will probably be
in Java or maybe C++ with a good widget library (GTKmm).  It just hurts
too much to write GUI apps in C.

> > Years ago, Philipe Khan of Borland said that 'C is a disease and the
> > Americans are spreading it.' Maybe he had this kind of thing in mind.
> 
> I don't think it is impossible to keep C's virtues while eliminating its
> more grievous faults.  But it will not be done by people who look down
> their long aristocratic noses at C, and scorn it as a peasant's language
> of no interest to them. 

One mans grievous fault is another mans shiningly useful feature. 
Language wise I think there is really only a few things that can/should
be done to improve C.  Largely they involve incorporating the more
sensible improvements from C++ and dropping most of the cruft.  I.E.
compile-time operator overloading would be nice but templates are
horrendous.  Beyond that though I think C would benefit most from more
code reuse.  Why is it that everyone has their own C libraries to handle
strings?  Things like Glib need to be more widely used, because
otherwise we're all just reinventing the wheel and reproducing the bugs.

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

--
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