Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity?
IMO the real problem is that software developers are still focussed on programming, not on specification. We should leave programming to computers, instead of wasting money paying people to do it and hoping that the resulting system meets user requirements, including some semblance of security. 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 - but rather, genuine immunity. Other security issues (like freedom from SQL injection and cross-site scripting attacks) may not always come free but are relatively easy to add to the specification, as long as people are aware of the need to do so. It amazes me that software development techniques have progressed so little in the last 50 years. In the 1950s we had assembler. This was followed in the 1960s by high level programming languages. Nearly 50 years later we have... slightly better high level programming languages. For example, one of the major languages in use today is C, which is more than 30 years old. The only significant advance since the invention of C (and Algol before it) is object-oriented programming - a welcome improvement, but far short of the paradigm shift that is desperately needed. Let's stop focussing on the minute detail of the steps that a computer needs to execute in order to solve a software problem, and turn our attention instead to describing what the program is supposed to achieve - including its resistance to hostile input. Until we do so, we will be doing little more than patching up outdated technology. David Crocker, Escher Technologies Ltd. Consultancy, contracting and tools for dependable software development www.eschertech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of SC-L Subscriber Dave Aronson Sent: 07 June 2007 13:53 To: SC-L@securecoding.org Subject: Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity? Michael S Hines [mailto:[EMAIL PROTECTED] writes: Product integration - why have an editor, separate source code analizer, separate 'lint' product, compiler, linker, object code analyzer, Fuzz testing tools, etc...apart from marketing and revenue stream - it doesn't help the developer any. It may. IME, all-in-one products usually integrate the pieces well. On the other claw, they don't tend to do most, if any, of the pieces well. On the third hand, integration doesn't have to mean they're no longer separate. They can play nicely together if they adhere to relevant standards for interoperability. Witness how you can develop a lot of software without leaving Emacs, or Eclipse. However, I don't think that's all that relevant to software security in particular, as opposed to software development in general. -Dave -- Dave Aronson Specialization is for insects. -Heinlein Work: http://www.davearonson.com/ Play: http://www.davearonson.net/ ___ 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. ___ ___ 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. ___
Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity?
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. -- Larry Kilgallen ___ 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. ___
Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity?
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 rCs 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. ___
Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity?
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. -- Larry Kilgallen ___ 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. ___
