Re: How Ada could have prevented the Red Code distributed denial ofservice attack.

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

David Lee Lambert wrote:
> On 1 Aug 2001, Robert Dewar wrote:
> > "Mike Smith" <smithmc@michaelsmithHATESSPAM.org> wrote in message news:<tmfvrpmb575l80@corp.supernews.com>...
> > > "raj" <israelrt@optushome.com.au> wrote in message
> > > news:ppsemtojqkqsqpfvj1th3mae8b4vu1tg89@4ax.com...
> > > >
> > > > The buffer overflow occurs because of an old and well known bug in the
> > > > C libraries.
> > >
> > > The buffer overflow occurs because of a bug in the *Microsoft* C library.
> > > This is not endemic to C or C++ in general.  And, what, no one has ever
> > > found a bug in Ada?
> >
> > Sounds like Mike is not familiar with Ada. Of course Ada does not
> > guarantee freedom from bugs, but for many reasons it does tend to
> > eliminate obvious goofs like buffer overruns, which are indeed
> > "endemic" to C and C++ in that these languages do not provide any
> > help for avoiding such bugs, and as we know these buffer overrun
> > bugs have time and time again proved weak spots in code written
> > in C/C++.
> 
> C++ makes it very easy to avoid buffer-overflow bugs:  just use the STL
> types 'string' (for strings) and 'vector<T>' (for arbitrary objects).

This _might_ be true if your String class was used everywhere -- but its
not. As long as you continue to have to use pointers to strings, arrays
of NUL terminated strings, calls to strncpy(), strcpy(), etc., you are
_still_ exposed to all the human foibals of array bounds errors and
abuse.

A vector<T> class is all fine and dandy too. But what will you use when
you call pipe(2)?  Why you'll use a naked int fd[2] array just like you
always did in C. So what's the problem you say?

void foo() {
   int fd[2];				// 2 file descriptors from pipe(2)

   if ( pipe(&fd[0]) != -1 ) {           // Create pipe with 2 fd's
      Call_Some_Other_Function(fd[2]);   // whoops -- no compiler help here

The compiler is no help here, and the runtime won't be either (you will
catch it eventually, when you try to do I/O on the value passed, but
you may be buried 15 function calls deep by then! Welcome to the 
debugger. ;-)

You still have array bounds issues (for the non C/C++ types, the
code tries to access fd[2] which is out of bounds).  Unless you STL
the entire POSIX suite, you _still_ have array bounds issues. Again,
if you use msgrcv(2)/msgsnd(2) you'll be using the naked char[] array
for the message, within the structure.  Your STL is no help to you
here.

This seems to be the type of issue that many C++ people forget in 
these discussions. Sure the STL (or any other class) can implement
checks in them. But it does _not_ change the dangers of the language
and all of the other infrastructure that is still with you.

Now in Ada, you may need to call pipe(2) or msgrcv(2)/msgsnd(2) also.
But in Ada, you have full checks in place (unless purposely disabled).
So the access to fd(2) (assuming array bounds 0..1) would have been
caught at compile time (because this can be determined statically).
If it had been more dynamic (accessed by variable subscript), it 
would immediately raise an exception at run time.

And you can define variant structures (records) to meet the need of
the msgsnd(2) call, for example. All access to the arrays are fully
checked, and bugs will be caught early in the testing, and caught
at the source. Not 15 function levels deep.

> Agreed that there is a lot of buggy C code out there.  Much of it is the
> result of assumptions made in laboratory conditions on machines with a lot
> of performance-limitations;  for instance,  80-column TTYs and printers
> and card-punches.  These assumptions started out with FORTRAN and other
> languages of that era;  C was the beginning of the process to supersede
> them.

Much of it is laziness. I have seen people use scanf() for things
they could have done safely themselves or by other means. I continue
to see atoi()/atol() or atof() used instead of strtol() for example
(atoi() blithly returns zero if the conversion from a string to 
integer fails). 

> It is true that C and C++ native types do not provide bounds-checking,
> although some compilers do bounds-checking for static arrays.  However, it
> would be trivial to make a type or system like vector<T> with the
> additional feature of doing automatic bounds-checking, or even
> automatically growing the array when adding a new element past the end.

But again, there are examples like the pipe(2) where this does not
solve the problem. Maybe growth is not the correct solution. Maybe
the access is a "bug" instead. ;-)

> I'm sure that one can write a secure webserver in Ada,  but I personally
> would trust a mission-critical system that I had written in C better,
> because I've had more experience with the language and the available
> environment.  I certainly would plan out such a system very carefully.
> 
> --
> DLL

You're expressing your decision based on your experience, which is fine. 
However, given that, what this thread boils down to now however (if Ada 
is the better language) is that someone else can write a more secure 
web server than you, because they are not handicapped by this lack 
of experience, using this better tool.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg