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: 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 23:05:20 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.ems.psu.edu!not-for-mail From: cross@augusta.math.psu.edu (Dan Cross) 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: 3 Aug 2001 02:05:19 -0400 Organization: Mememememememmeme Message-ID: <9kdeuv$dfh@augusta.math.psu.edu> References: <$Id63yuv4BjB@eisner.encompasserve.org> <3b6903f5.1111682555@news.worldonline.nl> <9kci3p$ri$1@elf.eng.bsdi.com> NNTP-Posting-Host: augusta.math.psu.edu X-Trace: boatanchor.ems.psu.edu 996818720 16001 146.186.132.2 (3 Aug 2001 06:05:20 GMT) X-Complaints-To: security@psu.edu NNTP-Posting-Date: 3 Aug 2001 06:05:20 GMT Xref: archiver1.google.com comp.lang.ada:11165 comp.lang.c:71821 comp.lang.c++:79553 comp.lang.functional:7237 Date: 2001-08-03T06:05:20+00:00 List-Id: In article <9kci3p$ri$1@elf.eng.bsdi.com>, Chris Torek wrote: >Others may use the terminology differently (e.g., interchangeably), >but I like this distinction -- it is like the one between tactics >and strategy. IMHO, the use of the term ``bug'' to describe an error in a piece of software is a cop-out on the part of software engineers and programmers. The term ``bug'' implies that it's beyond the control of the programmer, when in reality, software has no bugs which aren't placed there by the person who writes it (sometimes directly, sometimes indirectly). Was it Hoare who said something along the lines of, ``it's a lot easier for a programmer to say, `the software still has a few bugs' than to say, `the software is full of defects I put there.' '' My take on your distinctin between `bug' and `defect' is that software systems have to be evaluated in their totality, and that that totality contains multiple levels. Ie, requirements, design, implementation, etc. Defects can occur at any level, but they're still defects. The union of set of all requirements defects, design defects, and implementation defects (and others, if appropriate) forms the set of all defects of the system. To bring this back around to security for a moment.... I've long maintained that security is simply a proper subset of correctness at all levels; be it implementation, design, requirements, etc. Someone has proposed a definition that a correct program does what it's supposed to for all inputs, while a secure program does what it's supposed to and nothing else for all inputs. I think this is obtuse, however, since under what conditions does a correct program NOT do `nothing else'? Anyway, if we say for a moment that a correct program (and remember, this means ``correct at all levels'') is also a secure one, then using tools which reduce instances of implementation defects is a decent way to improve the security of software by cutting down on a whole class of potentially security compromising defects. Again, it comes back to choosing the appropriate tool for the job. Those who blindly pick C for everything are making a huge mistake, as are those who pick any other one language for all occasions. - Dan C.