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-01 14:25:53 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!151.189.0.75!newsfeed.germany.net!newsfeed2.easynews.net!easynews.net!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail From: Florian Weimer 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 of service attack. Date: Wed, 01 Aug 2001 23:40:13 +0200 Organization: Enyo's not your organization Message-ID: <87ae1jh32a.fsf@deneb.enyo.de> References: <5ee5b646.0108010949.5abab7fe@posting.google.com> <%CX97.14134$ar1.47393@www.newsranger.com> <9k9if8$rn3$1@elf.eng.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: archiver1.google.com comp.lang.ada:10988 comp.lang.c:71408 comp.lang.c++:79167 comp.lang.functional:7107 Date: 2001-08-01T23:40:13+02:00 List-Id: Chris Torek writes: > Ultimately, this boils down to an indisputable fact: people are > exploiting buffer overflows that exist because poorly written C > code is popular. But this practically begs for a new question: if > poorly-written Ada (or any other language) were popular instead, > would that mean there would be *no* exploitable bugs? The problem with buffer overflow bugs is that they are very hard to discover if the first audit occurs after the software has been out for years (and changed many times, by different persons). If you're coding from scratch, you can try to follow a rule that it must be obvious that there aren't any such problems, but that's not an option with existing code, and not many people seem to follow this route anyway. Other C-eminent problems (for example, bugs related to improper use of format strings) can be checked for almost automatically, so they aren't such a big problem. Other kinds of defects still have the potential of being very severe (for example, look at the recent problem with SSH 3.0.0). My subjective impression is that remote code injection attacks usually have far more potential for harm than these other defects, but this observation might just reflect the fact that in the latter cases, the impact of the vulnerability varies much more from defect to defect.