The Ariane 5 disaster was due to a variety of software development failures: process, reuse, design, and coding. the coding error was an uncaught exception resulting from a floating point to integer conversion error.
My only point was that choice of language does not in and of itself protect you from security/safety failures. rCs > At 9:16 AM -0400 6/10/07, Robert C. Seacord wrote: > >> ljknews, >> >> Yes, it is virtually impossible to get a serious runtime error in an Ada >> program. For example: >> >> http://www.youtube.com/watch?v=kYUrqdUyEpI >> > > It amazes me that someone in a discussion of software security would point > to a page that requires Javascript to be viewed. > > But I see the topic of the page was Ariane 5, a well known case of running > software in an environment other than that specified in the design of the > software. > > That is a management issue - my comments were about buffer overflows, > as were the comments of David Crocker which I quoted. If you have > secret knowledge that the Ariane 5 failure was related to buffer > overflows, please share it. > > Not reading what was going on, in fact, was the cause of the Ariene 5 > failure. > > >>> At 9:51 PM +0100 6/9/07, David Crocker wrote: >>> >>> >>> >>>> If instead we pay people to perform the more skilled tasks of establishing >>>> requirements and specifying the systems to meet them, and use computers to >>>> generate programs that meet the specifications, then such things as >>>> freedom from >>>> buffer overflow come free of charge. By "freedom" here, I don't mean the >>>> sort of >>>> freedom that comes in "safe" languages such as Ada and Java - in which the >>>> buffer overflow raises an exception, probably requiring a restart of the >>>> subsystem >>>> >>>> >>> In my experience with Ada 83, the potential for buffer overflow is detected >>> at compile time. When I get an unexpected runtime exception, it is almost >>> always at the interface to another language. >>> >>> > > _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
