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: <[EMAIL PROTECTED]> To: <sc-l@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@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 > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > 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 > ([EMAIL PROTECTED]) > 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 <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: Gary McGraw <[EMAIL PROTECTED]>, Florian Weimer <[EMAIL PROTECTED]>, > der Mouse <[EMAIL PROTECTED]> > Cc: SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="ISO-8859-1" > > > > 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 >> > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 20 Jul 2006 15:33:30 -0400 > From: [EMAIL PROTECTED] > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: Pascal Meunier <[EMAIL PROTECTED]> > Cc: der Mouse <[EMAIL PROTECTED]>, SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: Florian Weimer <[EMAIL PROTECTED]> > Cc: der Mouse <[EMAIL PROTECTED]>, SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="US-ASCII" > > > > > 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 > > > > > ------------------------------ > > Message: 5 > Date: Thu, 20 Jul 2006 16:20:07 -0400 > From: ljknews <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > 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 help > > It 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 <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: Florian Weimer <[EMAIL PROTECTED]> > Cc: der Mouse <[EMAIL PROTECTED]>, SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="US-ASCII" > > > > > 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 > > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 20 Jul 2006 16:59:35 -0400 > From: ljknews <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: <[EMAIL PROTECTED]>, "Wall, Kevin" <[EMAIL PROTECTED]> > Cc: SC-L@securecoding.org > Message-ID: > <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] > Sent: Thursday, July 20, 2006 3:25 PM > To: Wall, Kevin > Cc: Dana Epp; SC-L@securecoding.org > Subject: Re: [SC-L] bumper sticker slogan for secure software > >> BTW, does anyone besides me think that it's time to put this thread to > >> rest? > > 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 <[EMAIL PROTECTED]> > Subject: Re: [SC-L] bumper sticker slogan for secure software > To: SC-L@securecoding.org > Message-ID: <[EMAIL PROTECTED]> > 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@securecoding.org > http://krvw.com/mailman/listinfo/sc-l > > > End of SC-L Digest, Vol 2, Issue 124 > ************************************ > _______________________________________________ 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
