Secure Coding mailing list archives
bumper sticker slogan for secure software
From: mark at markgraff.com (Mark Graff)
Date: Fri, 21 Jul 2006 09:28:48 -0700
There's another point to consider, when talking about whether True Security is Possible. And I have to say I've never been happy with the forms I've found so far to express it... Security, in many cases, decays. It's like what we used to call, in the Old Days, "bit rot". Software that has "worked" "perfectly well" for years (that is, failures and mistakes have fallen under the threshold of detection) suddenly stop "working". Often, it's because some element of the environment in which the system runs has changed around it. It could be a library that the program uses, for instance. I suppose it could be a change in the way the software is used, or applied. So while most software decays in some way while it ages, I seem to observe that the security aspect of a program decays faster than the rest of it. (This has some analogies in the "real" world. Some parts of a car, for example, wear out faster than the rest. Tires and Brake pads. It's an interesting feature of good design, of course, to isolate the effects of wear and tear into parts intended to be disposable. But I digress.) I have therefore often wondered if we should be talking, not about how "secure" a system is, in a static sense, but rather what its security half-life is. This is the point of my hoary thought experiment (sorry if you've heard this one) in which we prepare a desktop with the latest and greatest in the way of anti-virus stuff, firewalls, OS patches, and so forth, then spin it down, shrink-wrap it, and put it in a closet. If we take it out a year later and spin it up, that system will be less sure--more likely to successfully be compromised--than it was when it was spun down. How fast security decays will vary, depending mostly on which OS and app software it runs and how corrosive, if you will, that part of the overall operating landscape (the Internet, say) is. This reasoning leads me to the thought that Mac OS X, for example, is "more secure" than Windows XP for reasons having nothing directly to do with design or implementation, but rather pertaining to its very ubiquity. XP, in this sense, is the center of the bullseye. Gee, maybe software systems emanate a modicum of "unsecurity gravity", so that if you get a great many of them together (that is, if millions and millions of people buy the product), security plummets, and declines as the square of the distance to True Dead Center of the day's commonplace platform. Or, to put it another way, this is why XP sucks. Well, I said I've never been happy with the way I've expressed this. -mg- ----- Original Message ----- From: <sc-l-request at securecoding.org> To: <sc-l at securecoding.org> Sent: Friday, July 21, 2006 5:05 AM Subject: SC-L Digest, Vol 2, Issue 124
Send SC-L mailing list submissions to sc-l at securecoding.org To subscribe or unsubscribe via the World Wide Web, visit http://krvw.com/mailman/listinfo/sc-l or, via email, send a message with subject or body 'help' to sc-l-request at securecoding.org You can reach the person managing the list at sc-l-owner at securecoding.org When replying, please edit your Subject line so it is more specific than "Re: Contents of SC-L digest..." Today's Topics: 1. Re: bumper sticker slogan for secure software (Pascal Meunier) 2. Re: bumper sticker slogan for secure software (leichter_jerrold at emc.com) 3. Re: bumper sticker slogan for secure software (Florian Weimer) 4. Re: bumper sticker slogan for secure software (Pascal Meunier) 5. Re: bumper sticker slogan for secure software (ljknews) 6. Re: bumper sticker slogan for secure software (Pascal Meunier) 7. Re: bumper sticker slogan for secure software (ljknews) 8. Re: bumper sticker slogan for secure software (Dana Epp) 9. Re: bumper sticker slogan for secure software (John Wilander) ---------------------------------------------------------------------- Message: 1 Date: Thu, 20 Jul 2006 15:11:06 -0400 From: Pascal Meunier <pmeunier at cerias.purdue.edu> Subject: Re: [SC-L] bumper sticker slogan for secure software To: Gary McGraw <gem at cigital.com>, Florian Weimer <fw at deneb.enyo.de>, der Mouse <mouse at rodents.montreal.qc.ca> Cc: SC-L at securecoding.org Message-ID: <C0E54D8A.13E6F%pmeunier at cerias.purdue.edu> Content-Type: text/plain; charset="ISO-8859-1" On 7/20/06 1:57 PM, "Gary McGraw" <gem at cigital.com> 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. gemBut 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:pmeunier at cerias.purdue.edu] Sent: Thu Jul 20 13:54:42 2006 To: Florian Weimer; der Mouse Cc: SC-L at securecoding.org Subject: Re: [SC-L] bumper sticker slogan for secure software On 7/20/06 11:58 AM, "Florian Weimer" <fw at deneb.enyo.de> 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 at 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 at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php------------------------------ Message: 2 Date: Thu, 20 Jul 2006 15:33:30 -0400 From: leichter_jerrold at emc.com Subject: Re: [SC-L] bumper sticker slogan for secure software To: pmeunier at cerias.purdue.edu Cc: mouse at rodents.montreal.qc.ca, SC-L at securecoding.org Message-ID: <Pine.SOL.4.61.0607201531110.20979 at mental> Content-Type: text/plain; charset="iso-8859-1" | >>>> 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... | > | > But people are forced to spend more time with the code, which | > generally helps them (in particular smart people) to eradicate bugs.... | | 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.... But always keep in mind a comment (allegedly, I've never actually seen this) present at the top of something Don Knuth wrote: Be careful with this code. I've only proved it correct, not actually tested it. If Don Knuth can say that about code, the rest of us should be very humble about our correctness proofs. -- Jerry ------------------------------ Message: 3 Date: Thu, 20 Jul 2006 21:46:22 +0200 From: Florian Weimer <fw at deneb.enyo.de> Subject: Re: [SC-L] bumper sticker slogan for secure software To: Pascal Meunier <pmeunier at cerias.purdue.edu> Cc: der Mouse <mouse at rodents.montreal.qc.ca>, SC-L at securecoding.org Message-ID: <87lkqojbzl.fsf at mid.deneb.enyo.de> Content-Type: text/plain; charset=us-ascii * 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. In other cases, languages have the reputation of being free from buffer overflows although it's just not true: You can create a fully conforming Common Lisp implementation where code injection through buffer overflows is possible. On the other hand, it's possible to construct an ISO C implementation where accessing memory beyond the end of a buffer is equivalent to calling abort. (Such CL implementations are very common, but the C implementatins aren't because they would feature a very unusual ABI or suffer from poor performance.) And you need to keep in mind that even with C, we are close to turning buffer overflows into completely reproducible crashes. This is not so much different from supposedly safer programming languages where an exception is raised in such cases. The exception can be handled, sure, but if it is truly unexpected, your system will fail.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. ------------------------------ Message: 4 Date: Thu, 20 Jul 2006 16:03:01 -0400 From: Pascal Meunier <pmeunier at cerias.purdue.edu> Subject: Re: [SC-L] bumper sticker slogan for secure software To: Florian Weimer <fw at deneb.enyo.de> Cc: der Mouse <mouse at rodents.montreal.qc.ca>, SC-L at securecoding.org Message-ID: <C0E559B5.13E7B%pmeunier at cerias.purdue.edu> Content-Type: text/plain; charset="US-ASCII" On 7/20/06 3:11 PM, "Florian Weimer" <fw at deneb.enyo.de> 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 ------------------------------ Message: 5 Date: Thu, 20 Jul 2006 16:20:07 -0400 From: ljknews <ljknews at mac.com> Subject: Re: [SC-L] bumper sticker slogan for secure software To: SC-L at securecoding.org Message-ID: <p05200f14c0e595c4ae4d@[192.168.1.254]> Content-Type: text/plain; charset="us-ascii" At 9:11 PM +0200 7/20/06, Florian Weimer wrote: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 helpIt helps so long as some of the languages chosen are those immune to buffer overflows. -- Larry Kilgallen ------------------------------ Message: 6 Date: Thu, 20 Jul 2006 16:28:07 -0400 From: Pascal Meunier <pmeunier at cerias.purdue.edu> Subject: Re: [SC-L] bumper sticker slogan for secure software To: Florian Weimer <fw at deneb.enyo.de> Cc: der Mouse <mouse at rodents.montreal.qc.ca>, SC-L at securecoding.org Message-ID: <C0E55F97.13E7E%pmeunier at cerias.purdue.edu> Content-Type: text/plain; charset="US-ASCII" On 7/20/06 3:46 PM, "Florian Weimer" <fw at deneb.enyo.de> 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 ------------------------------ Message: 7 Date: Thu, 20 Jul 2006 16:59:35 -0400 From: ljknews <ljknews at mac.com> Subject: Re: [SC-L] bumper sticker slogan for secure software To: SC-L at securecoding.org Message-ID: <p05200f16c0e59e7ebb4d@[192.168.1.254]> Content-Type: text/plain; charset="us-ascii" 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 ------------------------------ Message: 8 Date: Thu, 20 Jul 2006 15:44:38 -0700 From: "Dana Epp" <dana at vulscan.com> Subject: Re: [SC-L] bumper sticker slogan for secure software To: <michaelslists at gmail.com>, "Wall, Kevin" <Kevin.Wall at qwest.com> Cc: SC-L at securecoding.org Message-ID: <9AE3FC06F0A89A43A4D6F667955082C402D364 at sbsmain.Vulscan.local> Content-Type: text/plain; charset="us-ascii" Actually, Brian Shea got the points for emailing me that he knew it was the system error "Access Denied". An extra 10 points goes to Andrew van der Stock for his explaination that: "apparently the term originates from radio, where 5x5 means good reception and good signal strength (in that order). So 0x5 means - no reception ("0") - good signal strength ("5") ie, we're doing ok at getting our message out, but people aren't listening yet. " That cracked me up. So fitting for this forum. Regards, Dana Epp [Microsoft Security MVP] http://silverstr.ufies.org/blog/ -----Original Message----- From: mikeiscool [mailto:michaelslists at gmail.com] Sent: Thursday, July 20, 2006 3:25 PM To: Wall, Kevin Cc: Dana Epp; SC-L at securecoding.org Subject: Re: [SC-L] bumper sticker slogan for secure softwareBTW, does anyone besides me think that it's time to put this thread torest?I do. But i'm still waiting for my points from dana ...-kevin-- mic ------------------------------ Message: 9 Date: Fri, 21 Jul 2006 13:15:01 +0200 From: John Wilander <johwi at ida.liu.se> Subject: Re: [SC-L] bumper sticker slogan for secure software To: SC-L at securecoding.org Message-ID: <200607211115.k6LBFCoW007733 at portofix.ida.liu.se> Content-Type: text/plain; charset=us-ascii I've actually been using a secure software slogan for a few years, both in teaching and in pitching business. It's taken from Howard and LeBlanc's book "Writing Secure Code": - Security features are not secure features - The statement mesmerizes people and aguably needs a "necessarily" to be more precise. But it's short and does the trick for me---it separates adding security functions from trying to secure all functions in the system (during all phases). Regards, John ____________________________ John Wilander, PhD Student Computer and Information Sc. Linkoping University, Sweden http://www.ida.liu.se/~johwi ------------------------------ _______________________________________________ SC-L mailing list SC-L at securecoding.org http://krvw.com/mailman/listinfo/sc-l End of SC-L Digest, Vol 2, Issue 124 ************************************
Current thread:
- bumper sticker slogan for secure software, (continued)
- bumper sticker slogan for secure software ljknews (Jul 20)
- bumper sticker slogan for secure software John Wilander (Jul 21)
- bumper sticker slogan for secure software leichter_jerrold at emc.com (Jul 20)
- bumper sticker slogan for secure software Dana Epp (Jul 20)
- bumper sticker slogan for secure software mikeiscool (Jul 20)
- bumper sticker slogan for secure software Crispin Cowan (Jul 21)
- Cost of provably-correct code (was: bumper sticker slogan for secure software) David Crocker (Jul 21)
- Cost of provably-correct code (was: bumper sticker slogan for secure software) der Mouse (Jul 22)
- Cost of provably-correct code Crispin Cowan (Jul 23)
- bumper sticker slogan for secure software mikeiscool (Jul 23)
- bumper sticker slogan for secure software Crispin Cowan (Jul 21)
- security half-life and critical mass securecoding2dave at davearonson.com (Jul 21)