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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-02 07:40:38 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" 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: Thu, 2 Aug 2001 10:26:57 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9kbnvk$nf0$1@nh.pace.co.uk> References: <%CX97.14134$ar1.47393@www.newsranger.com> <9k9if8$rn3$1@elf.eng.bsdi.com> <9k9nci$1cq$1@nh.pace.co.uk> <9k9s85$s0o$1@elf.eng.bsdi.com> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 996762420 24032 136.170.200.133 (2 Aug 2001 14:27:00 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 2 Aug 2001 14:27:00 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:11085 comp.lang.c:71647 comp.lang.c++:79333 comp.lang.functional:7186 Date: 2001-08-02T14:27:00+00:00 List-Id: Well I would certainly agree (to a point) with your lock analogy. No language (or lock) is going to entirely prevent exploitable holes in systems because holes result from logic errors as well as simple programming errors. Hence, it is correct to conclude that if only Microsoft used Ada there would still be the possibility of security breeches. But I'd still argue that usage of a given language that includes stronger checks for errors ultimately results in a stronger lock. The stronger the lock, the less likelihood someone is going to break in - or at least you've reduced the number of thieves you've got to worry about. The fact that somewhere there exists one thief who can break any lock doesn't mean I should quit locking my front door. A more important question to toss out would be "What is the cost incurred when someone *does* find a hole to exploit and *does* break in?" If you are building an OS that is going to be used by web servers, that cost can be pretty high. If the cost is high, one ought to consider investing in the stronger lock rather than the dime-store-cheapie that can be got around with a bobby pin. That's where Microsoft might have a big advantage by developing an OS using Ada - it doesn't cover all the possible holes, but it sure is going to cover some non-trivial number of them and that might save them and their customers a lot of money by preventing some number of attacks. Call it "Insurance". MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Chris Torek" wrote in message news:9k9s85$s0o$1@elf.eng.bsdi.com... > In article <9k9nci$1cq$1@nh.pace.co.uk> > > No, not at all. I agree that there are (more or less) objective > measures that show that the defect rate in some languages (e.g., > Ada) is far lower than the defect rate in other languages (C, > assembler, etc). I will even agree with one who argues that it > would be harder to break into a system with 100 defects than one > with 1000. But as far as actual breakins go: > > >There you will find additional evidence that language choice *does* > >make a difference in terms of productivity and defects. > > Until you get the number of defects close to zero -- I am not sure > "how close" is required; obviously zero suffices, given an appropriate > definition of defects; but I think zero is also unachievable unless > given an inappropriate definition :-) -- there will still be > "exploitable bugs" in systems. My argument is that, if we somehow > achieved this more perfect world, the crackers would simply change > their tactics: instead of using easily-cracked buffer overflow > bugs, they would use more-difficult (but available today) tricks > like TCP session record and replay. > > The "real world" analogy of locks is useful here. Locks can keep > "mostly-honest" people honest, and the better the locks, the greater > this effect becomes. It is certainly foolish to say: "well, this > cheap lock does not stop some thieves, therefore we should eliminate > all locks" -- but it is equally foolish to say "aha, this more-expensive > lock stopped that particular thief, therefore we should all just > use this lock and decree perfection". > > In other words, I do not dispute that code written in Ada tends to > be better; I just think it is a mistake to go from there to "if > only Microsoft wrote in Ada, there would be no more Code-Reds."