Code Red worm and typed languages 
Author Message
 Code Red worm and typed languages

The buffer overflow exploit at the heart of the code red worm is a
consequence of 'c'-typed languages.  Buffer overflows are something
we've been dealing with for a human generation.  Lord knows how many
computer generations that is.

Doesn't it seem apparent that justifying a typed language on the basis
of performance is equivalent to justifying asbestos in air filters
because it is flame-retardant?

Chuck



Sun, 25 Jan 2004 06:56:58 GMT  
 Code Red worm and typed languages

I don't know why the programmers did not put a bound-check
in, regardless of language. Somewhere you have to
excplicity specify the size of some container. Even
in table-oriented-programming, if you let some hacker
fill up a table and hog-n-crash the disk (if a disk-capable
table engine) they will.

Thus, the step to check/give a size is a manual
programmer step; and one that *should* be done in
all systems software.

The problem here seems sloppy programming, not
bad languages (Although I am no fan of C).

Quote:
> The buffer overflow exploit at the heart of the code red worm is a
> consequence of 'c'-typed languages.  Buffer overflows are something
> we've been dealing with for a human generation.  Lord knows how many
> computer generations that is.

> Doesn't it seem apparent that justifying a typed language on the basis
> of performance is equivalent to justifying asbestos in air filters
> because it is flame-retardant?

> Chuck

-T-


Sun, 25 Jan 2004 08:56:56 GMT  
 Code Red worm and typed languages

Quote:
> The problem here seems sloppy programming, not
> bad languages (Although I am no fan of C).

You're right in that sloppy programming is the cause, however, it's easier
to be sloppy in certain languages more than others.

- Stephen



Sun, 25 Jan 2004 21:36:30 GMT  
 Code Red worm and typed languages

Quote:

> > The problem here seems sloppy programming, not
> > bad languages (Although I am no fan of C).

> You're right in that sloppy programming is the cause, however, it's easier
> to be sloppy in certain languages more than others.

While I agree with the answers - YES, also with topmind - I warn about
this topic being also put into comp.lang.c++ and gone into a _huge_
off-topic discussion about everything on earth, especially the (stupid)
question should we keep Ada and throw C++ or vice versa...

So I guess this is it.  Lame people can and will write lame code in
any/every language - regardless of its protections... And an over
protected language will make it quite impossible to use it on existing
platforms with the existing transaction/second demans...  Unfortunately.

A



Sun, 25 Jan 2004 21:49:02 GMT  
 Code Red worm and typed languages


Quote:
>The buffer overflow exploit at the heart of the code red worm is a
>consequence of 'c'-typed languages.  Buffer overflows are something
>we've been dealing with for a human generation.  Lord knows how many
>computer generations that is.
>Doesn't it seem apparent that justifying a typed language on the basis
>of performance is equivalent to justifying asbestos in air filters
>because it is flame-retardant?

The justification for staticly typed languages is not (or perhaps "should
not be") that they produce faster code than is provided by dynamic checks.
The justification should be that the types of bugs found at compile time for
staticly typed languages would be unacceptably expensive if found at run
time.

The C family of languages, unfortunately provides very little safety.
However, C has the advantage of being a ubiquitous language that provides
very low level access to the machine.  Typically, good C code includes many
dynamic checks of arguments, ranges etc.  Buggy C code does not.  Good C
code is slower than buggy C code.

--PeterD



Mon, 26 Jan 2004 10:58:57 GMT  
 Code Red worm and typed languages

Quote:

> The buffer overflow exploit at the heart of the code red worm is a
> consequence of 'c'-typed languages.

I think it's a consequence of the lack of garbage collection in C.  It's
that which makes it harder to manage dynamically allocated buffers, and
hence encourages programmers to use statically declared ones.  And it's
these which are the main source of overruns (together with the very
existance of the gets() function, of course).

Quote:
> Doesn't it seem apparent that justifying a typed language on the basis
> of performance is equivalent to justifying asbestos in air filters
> because it is flame-retardant?

No.  But if you'd said:  "justifying a language without GC on the basis of
performance is equivalent to..." then I'd agree.

    -- chris



Sun, 25 Jan 2004 15:30:07 GMT  
 Code Red worm and typed languages

Quote:
> The buffer overflow exploit at the heart of the code red worm is a
> consequence of 'c'-typed languages.  Buffer overflows are something
> we've been dealing with for a human generation.  Lord knows how many
> computer generations that is.

> Doesn't it seem apparent that justifying a typed language on the basis
> of performance is equivalent to justifying asbestos in air filters
> because it is flame-retardant?

If by "'c'=typed languages", you mean "C-type languages", then I agree
with you; if you mean "statically typed", then I don't.  Not that I'm
a fan of statically typed languages, but there's nothing about static
typing that prevents bounds checking, which is the source of these
problems.  The design of C applies the thinking "most of these arrays
should be big enough for this to work most of the time", and applies
it consistently throughout the entire language and standard library.

Incidentally, GNU C does an okay job of trying to reduce these
problems, by having functions that, rather than filling a
pre-allocated array, take as one of their arguments a pointer to a
pointer to an array, and when they return, that pointer to an array is
pointing to one that's large enough.  If they went one step further
and put a switch into gcc that compiles in bounds checking, it would
make for an almost-usable environment (in conjunction with a GC
library, of course).



Tue, 27 Jan 2004 04:34:31 GMT  
 Code Red worm and typed languages

Quote:

> > The problem here seems sloppy programming, not
> > bad languages (Although I am no fan of C).

> You're right in that sloppy programming is the cause, however, it's easier
> to be sloppy in certain languages more than others.

Correct.   This kind of problem is unlikely to have happened in a program
created in either Ada or Modula-3.   Some languages, those characterized
by their promiscuous use of curly-braces, lead all too easily to bad
programming, even though there are thousands of programmers using these
languages who, to their credit, would have prevented this kind of nonsense
because of their own due diligence.

Richard Riehle
AdaWorks Software Engineering



Tue, 27 Jan 2004 09:16:31 GMT  
 Code Red worm and typed languages

Quote:

> Incidentally, GNU C does an okay job of trying to reduce these
> problems, by having functions that, rather than filling a
> pre-allocated array, take as one of their arguments a pointer to a
> pointer to an array, and when they return, that pointer to an array is
> pointing to one that's large enough.  If they went one step further
> and put a switch into gcc that compiles in bounds checking, it would
> make for an almost-usable environment (in conjunction with a GC
> library, of course).

C++ also has std::vector<> to solve just this sort of problem. Why
people still use static buffer allocations for dynamically sized data is
beyond me.

Otis B



Wed, 28 Jan 2004 05:29:04 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. about code red worm and its offspring...

2. W32 Opaserv.worm a/k/a Opasoft.A Worm

3. Worm virus: W32/opaserv.worm.f

4. Red Herring (was: Bitten by dynamic typing...)

5. The Red Language

6. P-code, T-code and Uni-Code Intermediate Languages

7. P-code, T-code, and Uni-Code Intermediate Languages

8. C55aps10.exe Bombing every hour - Code Red?

9. Code Red

10. Code Red PITA

11. Nimda/Code Red Log File Entries

12. Fun with httpd logs and code red

 

 
Powered by phpBB® Forum Software