Re: [SC-L] Bumper sticker definition of secure software
mikeiscool wrote: On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote: Goertzel Karen wrote: I've been struggling for a while to synthesise a definition of secure software that is short and sweet, yet accurate and comprehensive. My favorite is by Ivan Arce, CTO of Core Software, coming out of a discussion between him and I on a mailing list about 5 years ago. Reliable software does what it is supposed to do. Secure software does what it is supposed to do, and nothing else. and what if it's supposed to take unsanitzed input and send it into a sql database using the administrators account? is that secure? supposed to goes to intent. If it is a bug that allows this, then it was not intentional. If it was intended, then (from this description) it was likely a Trojan Horse, and it is secure from the perspective of the attacker who put it there. IMHO, bumper sticker slogans are necessarily short and glib. There isn't room to put in all the qualifications and caveats to make it a perfectly precise statement. As such, mincing words over it is a futile exercise. Or you could just print a technical paper on a bumper sticker, in really small font :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Necessity is the mother of invention ... except for pure math ___ 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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Aronson If you really want to compress that to bumper-sticker size, how about Secure Software: Does what it's meant to. Period. This encompasses both can't be forced NOT to do what it's meant to do, and can't be forced to do what it's NOT meant to do. While I think this is the most concise formulation so far of what most readers on this list would mean and would understand, I think the non-security public does not think of security breaches in terms of software doing more than it was supposed to. My suggestion for a bumper sticker is therefore less conceptually crisp, but perhaps more accessible: Secure Software: Works even if you try to dupe it Nice question, though - Holger Peine -- Dr. Holger Peine, Security and Safety Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany Phone +49-631-6800-2134, Fax -1299 (shared) PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE 2BBB C126 A592 48EA F9F8 ___ 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
On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote: mikeiscool wrote: On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote: Goertzel Karen wrote: I've been struggling for a while to synthesise a definition of secure software that is short and sweet, yet accurate and comprehensive. My favorite is by Ivan Arce, CTO of Core Software, coming out of a discussion between him and I on a mailing list about 5 years ago. Reliable software does what it is supposed to do. Secure software does what it is supposed to do, and nothing else. and what if it's supposed to take unsanitzed input and send it into a sql database using the administrators account? is that secure? supposed to goes to intent. I don't know. I think there is a difference between this does what it's supposed to do and this has no design faults. That's all I was trying to highlight. The point remains though: trimming this down into a friendly little phrase is, IMCO, useless. If it is a bug that allows this, then it was not intentional. If it was intended, then (from this description) it was likely a Trojan Horse, and it is secure from the perspective of the attacker who put it there. IMHO, bumper sticker slogans are necessarily short and glib. There isn't room to put in all the qualifications and caveats to make it a perfectly precise statement. As such, mincing words over it is a futile exercise. Or you could just print a technical paper on a bumper sticker, in really small font :) Crispin -- 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 definition of secure software
mikeiscool wrote:
On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote:
supposed to goes to intent.
I don't know. I think there is a difference between this does what
it's supposed to do and this has no design faults. That's all I was
trying to highlight.
The difference between supposed to, design flaw, and implementation
flaw is entirely dependent on your level of abstraction:
* Executive: build a thingie that lets good guys in and keeps bad
guys out.
* Director: build an authentication engine that uses 2-factor
tokens to authenticate users and only then lets them in.
* Manager: use OpenSSL and this piece of glue to implement that
2-factor thingie.
* Coder: main() { ... :)
Errors can occur at any level of translation. When it does something
surprising, then the guy at the top can claim that it wasn't
supposed to do that, and if you dig hard enough, you will discover
*some* layer of abstraction where the vulnerability violates the upper
intent, but not the lower intent. Hence the bug.
Some example bugs at each level:
* Executive: forgot to specify who is a good guy
* Director: Forgot to provide complete mediation, so the attacker
could bypass the authenticator.
* Manager: the glue thingie allowed proper authentication tokens,
but also allowed tokens with a string value of 0.
* Coder: gets(token); ...
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com
Necessity is the mother of invention ... except for pure math
___
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] silver bullet: mjr
Hi all, The silver bullet episode featuring Marcus Ranum went live recently: http://www.cigital.com/silverbullet/ In the interview, we discuss software security progress briefly. BTW, I did an interview with the mysterious Dana Epp (silverstr) last week that is in the production pipeline. I'll let you all know when that goes live too. gem company www.cigital.com book www.swsec.com 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
[SC-L] bumper sticker slogan for secure software
mikeiscool [mailto:[EMAIL PROTECTED] writes: The point remains though: trimming this down into a friendly little phrase is, IMCO, useless. One of the common problems in trying to persuade the masses of ANYTHING, be it the importance of secure software, the factual or moral correctness of your political stances, etc., is how to communicate it so that they will understand and receive the message. You can easily confuse them, bore them, or turn them against yourself. Truly putting it on bumper stickers is likely to be useless, but this is a useful exercise in thinking how we could express the concept briefly and simply. Another useful thing would be if all engineers would enroll in Toastmasters, but that's another story. ;-) -Dave, Governor of Toastmasters Area 63 (District 27) ___ 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] (no subject)
Gary McGraw [mailto:[EMAIL PROTECTED] wrote: I wrote a book with viega a few years ago called building secure software... Yes, John gave us all copies. Didn't bother to get it autographed though. :-) it was not about that company (at all). It certainly was not about the horribly broken software I spent months banging my head against a wall trying to fix :-( P.s. I actually like ivan's quip as reported by crispy. Me too. It contains the ideas I was trying to convey, more clearly, but it's still too long to fit on a bumper sticker. :-) -Dave ___ 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
On Mon, 17 Jul 2006, Peter G. Neumann wrote: Forget the bumper sticker approach. Hey Peter. :) Well, one should forget the bumper-sticker approach if all us broing dry guys keep try to explain to people how math works. Instead, teling them: 1+1=? Didn't learn math, eh? Is bumper-sticker worthy, if pointless as an example. In other words: I read your email! When have you last audited your code? ___ 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
Gary, If you think security is a funny topic, try this one: http://haha.nu/funny/funny-math/ ___ 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
I prefer to define the opposite: Insecure Software is like a joke, Except others laugh at you I like it because: -it captures the notion that vulnerabilities, just like jokes, are very often made apparent by thinking in a different context from the software's designers (the straight man). -It conveys the notion that insecure software is shoddy; -It conveys the notion that there are people who will find out that you run insecure software; -It may motivate some people to care about security by invoking social stigma ;) Cheers, Pascal Meunier Purdue University CERIAS On 7/15/06 3:27 PM, Goertzel Karen [EMAIL PROTECTED] wrote: I've been struggling for a while to synthesise a definition of secure software that is short and sweet, yet accurate and comprehensive. Here's what I've come up with: Secure software is software that remains dependable despite efforts to compromise its dependability. Agree? Disagree? -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703-902-6981 [EMAIL PROTECTED] ___ 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 definition of secure software
Crispin Cowan wrote:
mikeiscool wrote:
On 7/17/06, Crispin Cowan [EMAIL PROTECTED] wrote:
supposed to goes to intent.
I don't know. I think there is a difference between this does what
it's supposed to do and this has no design faults. That's all I was
trying to highlight.
The difference between supposed to, design flaw, and implementation
flaw is entirely dependent on your level of abstraction:
* Executive: build a thingie that lets good guys in and keeps bad
guys out.
* Director: build an authentication engine that uses 2-factor
tokens to authenticate users and only then lets them in.
* Manager: use OpenSSL and this piece of glue to implement that
2-factor thingie.
* Coder: main() { ... :)
Errors can occur at any level of translation. When it does something
surprising, then the guy at the top can claim that it wasn't
supposed to do that, and if you dig hard enough, you will discover
*some* layer of abstraction where the vulnerability violates the upper
intent, but not the lower intent. Hence the bug.
Some example bugs at each level:
* Executive: forgot to specify who is a good guy
* Director: Forgot to provide complete mediation, so the attacker
could bypass the authenticator.
* Manager: the glue thingie allowed proper authentication tokens,
but also allowed tokens with a string value of 0.
* Coder: gets(token); ...
Crispin
Yep...there are plenty of things that can go wrong. There are also plenty of
rather clever attacks. Designing a system requires much more complete thought
and a comprehensive viewpoint to have a hope...
As one very very minor example consider:
Authentication only for a payment rather resembles a check with only a
signature.
Glenn Everhart
___
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] Resource limitation
On Mon, Jul 17, 2006 at 05:48:59PM -0400, [EMAIL PROTECTED] wrote: I was recently looking at some code to do regular expression matching, when it occurred to me that one can produce fairly small regular expressions that require huge amounts of space and time. There's nothing in the slightest bit illegal about such regexp's - it's just inherent in regular expressions that such things exist. Yeah... the set of regular languages is big. And, some have pretty pathological FSM representations. In addition, the kinds of resources that you can exhaust this way is broader than you'd first guess. Memory is obvious; overrunning a thread stack is perhaps less so. ... How about file descriptors? File space? Available transmission capacity for a variety of kinds of connections? One place to look is capability systems. They're more flexible and should have all the features you want, but are still largely theoretical. http://en.wikipedia.org/wiki/Capability-based_security That said, every decent Unix system I'm aware of has ulimit, which you can use to restrict virtual memory allocations, total open files, etc: nash @ quack% ulimit -a ... virtual memory(kbytes, -v) unlimited nash @ quack% ulimit -v 1024 # just 1M RAM, this'll be fun :-) nash @ quack% ( find * ) find: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory Alternately, you can implement your own allocator library for your application and then impose per-thread limits using that library. How you do that is going to depend alot on the language. Obviously, there are lots for C/C++ floating around. http://en.wikipedia.org/wiki/Memory_allocation In Java, you don't get nice knobs on Objects and Threads, but you get several nice knobs on the VM itself: -Xm, -XM, etc. Other high level languages have similar problems to Java. I.e., how do you abstract the size of a thing when you don't give access to memory as a flat byte array? Well, you can do lots of fun things using LIFO queues, or LRU caches, and so forth. There are performance impacts to consider, but they you can often tweak things so it sucks primarily for the abuser. None of these is really that hard to implement. So, do we really need new theory for this? Dunno. One's mileage does vary. -nash -- the lyf so short, the craft so long to lerne. - Geoffrey Chaucer ___ 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
