From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107f24,582dff0b3f065a52 X-Google-Attributes: gid107f24,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-04 20:00:08 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!netnews.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc2.on.home.com.POSTED!not-for-mail Message-ID: <3B6CB6BA.95BADF23@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional Subject: Re: How Ada could have prevented the Red Code distributed denial ofservice attack. References: <3B6555ED.9B0B0420@sneakemail.com> <87n15lxzzv.fsf@deneb.enyo.de> <3B672322.B5EA1B66@home.com> <5ee5b646.0108010949.5abab7fe@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 05 Aug 2001 03:00:07 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 996980407 24.141.193.224 (Sat, 04 Aug 2001 20:00:07 PDT) NNTP-Posting-Date: Sat, 04 Aug 2001 20:00:07 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:11301 comp.lang.c:72231 comp.lang.c++:80026 comp.lang.functional:7307 Date: 2001-08-05T03:00:07+00:00 List-Id: David Lee Lambert wrote: > On 1 Aug 2001, Robert Dewar wrote: > > "Mike Smith" wrote in message news:... > > > "raj" 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' (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 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 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