Re: [SC-L] bumper sticker slogan for secure software
On 7/20/06, Andrew van der Stock [EMAIL PROTECTED] wrote: Actually, it is a myth. For every non-trivial system, there are business pressures on resourcing, deadlines, and acceptable quality (pick any two). Once a business has set their taste for risk, it makes no sense to spend say $10m on security controls on a product and delay it for six months which may only bring in $2m in revenue in total, or none at all if the company runs out of money to bring it to market. At the moment, most companies neither accept or assign the risk, enumerate the risk correctly, nor take adequate steps to eliminate as much risk as possible. We need to improve all three aspects. Even in a perfect world, there will still be bugs and security defects. Let's make sure that the remaining ones are really hard to exploit, and when the exploit happens, not much loss occurs. yeah. but none of this changes the fact that it IS possible to write completely secure code. thanks, Andrew -- mic ___ 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
Re: [SC-L] bumper sticker slogan for secure software
yeah. but none of this changes the fact that it IS possible to write completely secure code. -- mic And it IS possible that a man will walk on Mars someday. But its not practical or realistic in the society we live in today. I'm sorry mic, but I have to disagree with you here. It is EXTREMELY difficult to have code be 100% correct if an application has any level of real use or complexity. There will be security defects. The weakest link here is the human factor, and people make mistakes. More importantly, threats are constantly evolving and what you may consider completely secure today may not be tomorrow when a new attack vector is recognized that may attack your software. And unless you wrote every single line of code yourself without calling out to ANY libraries, you cannot rely on the security of other libraries or components that may NOT have the same engineering discipline that you may have on your own code base. Ross Anderson once said that secure software engineering is about building systems to remain dependable in the face of malice, error, or mischance. I think he has something there. If we build systems to maintain confidentiality, integrity and availability, we have the ability to fail gracefully in a manner to recover from unknown or changing problems in our software without being detrimental to the user, or their data. I don't think we should ever stop striving to reach secure coding nirvana. But I also understand that in the real world we are still in our infancy when it comes to secure software as a discipline, and we still have much to learn before we will reach it. Regards, Dana Epp [Microsoft Security MVP] http://silverstr.ufies.org/blog/ ___ 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
Re: [SC-L] bumper sticker slogan for secure software
* der Mouse: Absolute security is a myth. As is designing absolutely secure software. I have high hopes in formal methods. All formal methods do is push bugs around. Basically, you end up writing in a higher-level language (the spec you are formally verifying the program meets). You are then subject to the bugs present in *that* program (the spec) and the bugs present in the compiler (the formal verifier). But people are forced to spend more time with the code, which generally helps them (in particular smart people) to eradicate bugs. Another way to achieve the same thing is to freeze the code base and let it mature over decades, but I don't see the business model for that. ___ 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
Re: [SC-L] Bumper sticker definition of secure software
* Brian A. Shea: My slogan: Unsecured Applications = Unsecured Business Which is completely acceptable if you and your business partners are aware of the risk level at which your are running your company. Secure software costs more, requires more user training, and fails in hard-to-understand patterns. If you really need it, you lose. ___ 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
Re: [SC-L] bumper sticker slogan for secure software
Dana, Regarding your remarks about writing perfectly secure code... well put. And your remarks about Ross Anderson... Ross Anderson once said that secure software engineering is about building systems to remain dependable in the face of malice, error, or mischance. I think he has something there. If we build systems to maintain confidentiality, integrity and availability, we have the ability to fail gracefully in a manner to recover from unknown or changing problems in our software without being detrimental to the user, or their data. remined me of Anderson and Ralph Needham coining the phrase (hope I'm getting this right) that security is like programming Satan's computer in the sense that you have an evil extremely intelligent adversary with unlimited resources and time, etc. [http://www.cl.cam.ac.uk/ftp/users/rja14/satan.pdf] So there's a bumper sticker for you: Security: programming Satan's computer Of course, it's likely to be misunderstood by most. (Maybe we could attribute it to SNL's church lady. Sorry Ross. ;-) BTW, does anyone besides me think that it's time to put this thread to rest? -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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] Google Auditing
Hi guys! A few days ago, following the announcements by Dan from Websense and then HD, I wrote a post covering what they have done and what the future may gold for Google hacking for security purposes. http://blogs.securiteam.com/index.php/archives/513 Today a guy posted a blog on using the filetype: feature to find coding errors: http://www.cipher.org.uk/index.php?p=projects/bugle.project Gadi. ___ 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
Re: [SC-L] bumper sticker slogan for secure software
On 7/20/06 11:58 AM, Florian Weimer [EMAIL PROTECTED] wrote: * der Mouse: Absolute security is a myth. As is designing absolutely secure software. I have high hopes in formal methods. All formal methods do is push bugs around. Basically, you end up writing in a higher-level language (the spec you are formally verifying the program meets). You are then subject to the bugs present in *that* program (the spec) and the bugs present in the compiler (the formal verifier). But people are forced to spend more time with the code, which generally helps them (in particular smart people) to eradicate bugs. Another way to achieve the same thing is to freeze the code base and let it mature over decades, but I don't see the business model for that. Also, writing it twice with different languages, especially at different levels of abstraction, makes it less likely that the same bugs will appear in both. You can choose the higher level language so that it has great expressive power exactly for the things that are a pain to capture and verify (and thus a source of bugs) in the lower-level language. Last time I checked, formal methods were even able to catch design errors in some networking protocols. But you're right, they are not absolutely perfect because the tools and operators aren't, etc... That doesn't mean they can't help a great deal. I have great hopes for their usefulness. Maybe some day they will help so much that the distinction between what they can produce and absolutely secure software will become too small to matter. Whether we'll still be alive when that happens is another question. Pascal ___ 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
Re: [SC-L] bumper sticker slogan for secure software
I'm afraid that's not true. John Knight has a famous paper that shows that design/requirements bugs persist in n-version programming paradigms. I'll let the interested people google that one up for themselves. gem company www.cigital.com. podcast www.cigital.com/silverbullet book www.swsec.com -Original Message- From: Pascal Meunier [mailto:[EMAIL PROTECTED] Sent: Thu Jul 20 13:54:42 2006 To: Florian Weimer; der Mouse Cc: SC-L@securecoding.org Subject:Re: [SC-L] bumper sticker slogan for secure software On 7/20/06 11:58 AM, Florian Weimer [EMAIL PROTECTED] wrote: * der Mouse: Absolute security is a myth. As is designing absolutely secure software. I have high hopes in formal methods. All formal methods do is push bugs around. Basically, you end up writing in a higher-level language (the spec you are formally verifying the program meets). You are then subject to the bugs present in *that* program (the spec) and the bugs present in the compiler (the formal verifier). But people are forced to spend more time with the code, which generally helps them (in particular smart people) to eradicate bugs. Another way to achieve the same thing is to freeze the code base and let it mature over decades, but I don't see the business model for that. Also, writing it twice with different languages, especially at different levels of abstraction, makes it less likely that the same bugs will appear in both. You can choose the higher level language so that it has great expressive power exactly for the things that are a pain to capture and verify (and thus a source of bugs) in the lower-level language. Last time I checked, formal methods were even able to catch design errors in some networking protocols. But you're right, they are not absolutely perfect because the tools and operators aren't, etc... That doesn't mean they can't help a great deal. I have great hopes for their usefulness. Maybe some day they will help so much that the distinction between what they can produce and absolutely secure software will become too small to matter. Whether we'll still be alive when that happens is another question. Pascal ___ 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 This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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
Re: [SC-L] bumper sticker slogan for secure software
On 7/20/06 1:57 PM, Gary McGraw [EMAIL PROTECTED] wrote: I'm afraid that's not true. John Knight has a famous paper that shows that design/requirements bugs persist in n-version programming paradigms. I'll let the interested people google that one up for themselves. gem But it's true for stupid bugs like buffer overflows and format string vulnerabilities, in which we're still swimming, and the proof is the fact that those aren't possible in some languages. For design/requirements bugs, I'm reading: Why Are Formal Methods Not Used More Widely? John C. Knight Colleen L. DeJong Matthew S. Gibble Luís G. Nakano Department of Computer Science University of Virginia Charlottesville, VA 22903 http://www.cs.virginia.edu/~jck/publications/lfm.97.pdf and the evidence is that engineers presented with formal specifications were able to spot many design errors (Validation by inspection was effective). Therefore if you have a formal, high-level version it can be validated better, and formal methods give proof that the lower-level code conforms. I call that all-around better, and I'm hoping for more of it and better ways to do it. Now if you order a cat and needed a dog, nobody can help you. Pascal -Original Message- From: Pascal Meunier [mailto:[EMAIL PROTECTED] Sent: Thu Jul 20 13:54:42 2006 To: Florian Weimer; der Mouse Cc: SC-L@securecoding.org Subject: Re: [SC-L] bumper sticker slogan for secure software On 7/20/06 11:58 AM, Florian Weimer [EMAIL PROTECTED] wrote: * der Mouse: Absolute security is a myth. As is designing absolutely secure software. I have high hopes in formal methods. All formal methods do is push bugs around. Basically, you end up writing in a higher-level language (the spec you are formally verifying the program meets). You are then subject to the bugs present in *that* program (the spec) and the bugs present in the compiler (the formal verifier). But people are forced to spend more time with the code, which generally helps them (in particular smart people) to eradicate bugs. Another way to achieve the same thing is to freeze the code base and let it mature over decades, but I don't see the business model for that. Also, writing it twice with different languages, especially at different levels of abstraction, makes it less likely that the same bugs will appear in both. You can choose the higher level language so that it has great expressive power exactly for the things that are a pain to capture and verify (and thus a source of bugs) in the lower-level language. Last time I checked, formal methods were even able to catch design errors in some networking protocols. But you're right, they are not absolutely perfect because the tools and operators aren't, etc... That doesn't mean they can't help a great deal. I have great hopes for their usefulness. Maybe some day they will help so much that the distinction between what they can produce and absolutely secure software will become too small to matter. Whether we'll still be alive when that happens is another question. Pascal ___ 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 This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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 ___ 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
Re: [SC-L] bumper sticker slogan for secure software
On 7/20/06 3:46 PM, Florian Weimer [EMAIL PROTECTED] wrote: * Pascal Meunier: But it's true for stupid bugs like buffer overflows and format string vulnerabilities, in which we're still swimming, and the proof is the fact that those aren't possible in some languages. Could you name a few such language implementations? 8-) In most cases, the components that enforces the absence of buffer overflows are written in C. snip That's irrelevant. What is important is that some magic formal tool could say that some code in language A, where bug of type k is possible, is not equivalent to the version in language B, where type k bugs are impossible, ergo you have found a type k bug (in the absence of any other bug in that section of code...). I know someone is going to ask, why didn't you code it only in language B then?, to which there can be many different answers, and I don't want to get into that. For design/requirements bugs, I'm reading: Safety-critical software is a very different beast. You can make much stronger assumptions about the environment. It's not clear if the results apply to software security in open system. I'm not saying that formal methods have no value. But I doubt that comparisons with projects at completely different dollars-per-line-of-code levels give immediate insights. That's one of the things I'm hoping for: that more and better formal methods become more affordable and practical. Spark, for example, demonstrated that the costs of some formal methods were much lower than what people expected, in real projects. That gives me hope. Pascal ___ 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
Re: [SC-L] bumper sticker slogan for secure software
On 7/20/06 3:11 PM, Florian Weimer [EMAIL PROTECTED] wrote: * Pascal Meunier: Also, writing it twice with different languages, especially at different levels of abstraction, makes it less likely that the same bugs will appear in both. Algorithmic issues such as denial of service attacks through unbalanced binary trees or hash table collisions are pretty independent of the programming language and have been observed in many incarnations. If you implement the same protocol, it's likely that you end up with similar bugs. The DNS compression loop bug was reinvented many times. The fundamental mismatch in OpenPGP between key certification (key plus user ID) and key usage (just the key alone) affected many independently developed implementations. Chrome spoofing is ubiquitous in web browsers. Most things in this list are implemented in C or C++, but the problems are at such a high level that it's unlikely that a different choice of wildly different programming language would make a huge difference. If you look at lower-level bugs, such as buffer overflows, I hope that nobody still thinks that multiple code versions help -- just look at the long list (even after discounting direct code copies) of botched ASN.1 decoders. Some protocols are extremly hard to implement correctly, I'm afraid. (And not all protocols are unnecessarily complex.) It's obvious that if you just translate a bad, complicated algorithm or protocol from one language to the next, they'll all be bad. It remains that sometimes when you make people say something stupid twice they catch on the second time, especially during code reviews, because they re-express the code using natural language. That's why I said, less likely. It works with some and not others. Pascal ___ 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
Re: [SC-L] bumper sticker slogan for secure software
At 9:46 PM +0200 7/20/06, Florian Weimer wrote: * Pascal Meunier: But it's true for stupid bugs like buffer overflows and format string vulnerabilities, in which we're still swimming, and the proof is the fact that those aren't possible in some languages. Could you name a few such language implementations? 8-) Ada ! In most cases, the components that enforces the absence of buffer overflows are written in C. Not in VAX/DEC/Compaq/HP Ada, which is the one that I use. But the components that enforce the absence of buffer overflows are not written in Bliss (the language of the Ada RTL for that compiler) either. They are in the code that is generated, or the failure to generate that code because the problem was caught at compile time. -- 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
