Re: [SC-L] Compilers
On 12/22/06, Gary McGraw [EMAIL PROTECTED] wrote: I have a better idead. Stop using C++. Jeeze. Even better then that; stop programming insecurely. gem *rolleyes* -- 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 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/13/06, Glenn and Mary Everhart [EMAIL PROTECTED] wrote: Crispin Cowan wrote: Al Eridani wrote: On 11/9/06, Crispin Cowan [EMAIL PROTECTED] wrote: Prior to Java, resorting to compiling to byte code (e.g. P-code back in the Pascal days) was considered a lame kludge because the language developers couldn't be bothered to write a real compiler. Post-Java, resorting to compiling to machine code is considered a lame kludge because the language developers cannot be bothered to write a real optimizer. I don't see what a bytecode intermediate stage has to do with real optimizer. Very sophisticated optimizers have existed for native code generators for a very long time. Bytecode interpreter performance blows goats, so I'm going to assume you are referring to JIT. The first order effect of JIT is slow startup time, but that's not an advantage either. So you must be claiming that dynamic profiling (using runtime behavior to optimize code) is a major advantage. It had better be, because the time constraints of doing your optimization at JIT time restrict the amount of optimization you can do vs. with a native code generator that gets to run off-line for as long as it needs to. But yes, dynamic profiling can be an advantage. However, its use is not restricted to bytecode systems. VMware, the Transmeta CPU, and DEC's FX86 (virtual machine emulation to run x86 code on Alpha CPUs) use dynamic translation to optimize performance. It works, in that those systems all do gain performance from dynamic profiling, but note also the reputation that they all have for speed: poor. And then there's write once, run anywhere. Yeah ... right. I've run Java applets, and Javascript applets, and the latter are vastly superior for performance, and worse, all too often the Java applets are not run anywhere, they only run on very specific JVM implementations. There's the nice property that bytecode can be type safe. I really like that. But the bytecode checker is slow; do people really run it habitually? More important; is type safety a valuable property for *untrusted code* that you are going to have to sandbox anyway? So I give up; what is it that's so great about bytecode? It looks a *lot* like the Emperor is not wearing clothes to me. Crispin Considering that on VMS, due to the use everywhere of a single calling standard and a linker that can understand things, you can link any language with any other language and get things to run. A single app with some pieces in Fortran, C, Pascal, BASIC, and assembly language, all in one program, is perfectly feasible. I have worked with such. Everything's compiled, everything compiles to optimised machine code, and there is no interpreter needed. So why does anyone consider that multilingual development requires some kind of interpretive runtime? The old P-system was current a LONG time ago now, always did have speed problems (and took down some pretty decent apps with that ship in its day because they couldn't run as fast as native code ones). If there is some construct that NEEDS to be interpreted to gain something, it can be justified on that basis. Using interpretive runtimes just to link languages, or just to achieve portability when source code portability runs pretty well thanks, seems wasteful to me. You think source code portability is good enough such that runtime portability isn't really needed? Anybody know why .net uses a runtime of the sort it does? Because .net is microsofts clone of Java, so they copied everything. Glenn Everhart -- 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/14/06, ljknews [EMAIL PROTECTED] wrote: At 10:31 PM +1100 11/13/06, mikeiscool wrote: On 11/13/06, Glenn and Mary Everhart [EMAIL PROTECTED] wrote: If there is some construct that NEEDS to be interpreted to gain something, it can be justified on that basis. Using interpretive runtimes just to link languages, or just to achieve portability when source code portability runs pretty well thanks, seems wasteful to me. You think source code portability is good enough such that runtime portability isn't really needed? Anything beyond source code portability tempts the customer into use on a platform where the developer has not tested. But it has been tested, because if it runs on that jvm it has been tested for that JVM. a JVM version x on linux is the same as a JVM version x on windows. That's the point. Now maybe they try running it with a version x - 5 JVM, well fine, it may not work, but the response would be: duh. -- Larry Kilgallen -- 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/14/06, Leichter, Jerry [EMAIL PROTECTED] wrote: | If there is some construct that NEEDS to be interpreted to gain | something, it can be justified on that basis. Using interpretive | runtimes just to link languages, or just to achieve portability | when source code portability runs pretty well thanks, seems | wasteful to me. | | You think source code portability is good enough such that runtime | portability isn't really needed? | | Anything beyond source code portability tempts the customer into use | on a platform where the developer has not tested. | | But it has been tested, because if it runs on that jvm it has been | tested for that JVM. a JVM version x on linux is the same as a JVM | version x on windows. That's the point. Now maybe they try running it | with a version x - 5 JVM, well fine, it may not work, but the response | would be: duh. That would be nice, wouldn't it? Unfortunately, painful experience says it's not so. At least not for applications with non-trivial graphics components, in particular. The joke we used to make was: The promise of Java was Write once, run everywhere. What we found was Write once, debug everywhere. Then came the Swing patches, which would cause old bugs to re-appear, or suddenly make old workaround cause problems. So the real message of Java is Write once, debug everywhere - forever. Now, I'm exagerating for effect. There are Java programs even quite substantial Java programs, that run on multiple platforms with no problems and no special porting efforts. (Hell, there are C programs with the same property!) But there are also Java programs that cause no end of porting grief. It's certainly much more common to see porting problems with C than with Java, but don't kid yourself: Writing in Java doesn't guarantee you that there will be no platform issues. True, but that doesn't mean runtime portability isn't a good thing to aim for. -- 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] Could I use Java or c#? [was: Re: re-writing college books]
And then there's write once, run anywhere. Yeah ... right. I've run Java applets, and Javascript applets, and the latter are vastly superior for performance, and worse, all too often the Java applets are not run anywhere, they only run on very specific JVM implementations. You really can't judge java based on java applets; they are a really poor front, for reasons I assume you are aware. There's the nice property that bytecode can be type safe. I really like that. But the bytecode checker is slow; do people really run it habitually? More important; is type safety a valuable property for *untrusted code* that you are going to have to sandbox anyway? I believe major application servers run with -verify, which is appropriate and useful for them. So I give up; what is it that's so great about bytecode? It looks a *lot* like the Emperor is not wearing clothes to me. I think you just want to see him that way ;) 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/9/06, SZALAY Attila [EMAIL PROTECTED] wrote: Hi All, On Thu, 2006-11-09 at 10:20 +1100, mikeiscool wrote: You can definately get appropriate information via the stack trace with java's exception handling. It's strange to see you say debugging is _eaiser_ in c, typically people find it far easier in a managed language :) People are different. :)) I personally want to know what happens and I don't believe anything waht I can't see. In C I can see the assembly code what (I hope) is a deterministic thing. An interpreter is to big (to me) to think about it as a deterministic thing. And yes, with ``normal'' bugs a managed language could give me more possibility to find the place of the problem. But I want to hope, that we don't commit normal bugs. :) So basically you are expecting the only thing to go wrong on your program is to be bugs in the VM? Be it java or c#? I find that really strange. Sure, there have been bugs in the JVM/C# VM but just the same there have been bugs in windows that will affect your c programs. I really don't see that being a feasible/likely enough scenario to not use one of these languages. And with mysterious bugs, when you cannot reproduce it in a test system, just the costumer some hundred miles away, I think that the stability of the compiled code (and the core file what may created) is give more more chance to find the right place. Right exactly, and the fact that you have a stable VM instead of a strange-patched-level of windows/linux os gives you a stable platform. -- 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/8/06, SZALAY Attila [EMAIL PROTECTED] wrote: Hi All! On Mon, 2006-11-06 at 23:23 +1100, mikeiscool wrote: Hold the phone ... What debugging problems? What _specific_ speed issues? I'd be really surprised if your project couldn't be resolved with java; what specific problems are you facing? What tests have you run/consider to show that java's supposed speed issues will give you trouble? If it's just xml processing I'd say efficient data structures are what you care about, so java can help you there. 1. Debug When the program do something nasty or unwanted thing then in C I could do a lot of thing to find what happened. For example I could make the program dropping a core and analyze it at home. This needed because the program used some places where I cannot go into. And there were bugs in program which is definitely a race condition what is hard to reproduce. So it's not enough to write the steps to reproduce the bug. And I'm not sure that I can get the complete state of the program (and just the program) so I can detect where is the problem, even when the problem is in the compiler. I think it's more harder in java language. You can definately get appropriate information via the stack trace with java's exception handling. It's strange to see you say debugging is _eaiser_ in c, typically people find it far easier in a managed language :) 2. Speed Yes, it's maybe an outdated information but for example if there are a java plugin in my web browser (not javascript, java, for example the terminal plugin in some management page of AMD64 servers) or the ``famous'' Hungarian social web page iWIW, which was programmed in JAVA and was slow like Hell. That's a java applet; please don't judge Java the language based on applets; they are a really bad representation. Serverside java will be very effective and useful; what sort of client are you writing? Is it a website or a desktop app? Even if it's a desktop app, perhaps look to azureus to see a good, well running app written in java for the desktop. There are others. -- 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] Could I use Java or c#? [was: Re: re-writing college books]
On 11/6/06, SZALAY Attila [EMAIL PROTECTED] wrote: Hi All! I read this thread and I little be afraid. I'm just ahead of a complete rewriting of my program. The previous code was written in pure C (with an OOP looks-like somewhere). This program should run on Linux, freebsd and windows platform. This program is a GUI, so it has a graphical interface too but do a lot of computing and xml handling. I know C the most, so C++ is the least step I have to do. But I'm uncertain now that this is enough. When I have looked around for OO alternatives the C# was dropped, because I couldn't find a cross-platform graphical tools and Java was dropped because it's speed and the possibilities of debugging problems. Hold the phone ... What debugging problems? What _specific_ speed issues? I'd be really surprised if your project couldn't be resolved with java; what specific problems are you facing? What tests have you run/consider to show that java's supposed speed issues will give you trouble? If it's just xml processing I'd say efficient data structures are what you care about, so java can help you there. Is there any other alternatives or I left something or the C++ is the only alternative for me? Certainly not. If all else fails you can write memory-intensive stuff in a dll and import it into one java or c#. It'll still be some lower-level coding (in c++ or c or asm) but at least it'll be isolated. You'll need to explain your program more ... -- 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] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On 10/28/06, David Crocker [EMAIL PROTECTED] wrote: Crispin Cowan wrote: For me, the enemy in the room is C++. It gives you the safety of C with the performance of SmallTalk. There is no excuse at all to be writing anything in C++ yet vastly too many applications are written in C++ anyway. Instead of trying to coax developers to switch from C++ to something weird like SML, lets encourage them to switch to Java or C#, which are closer to their experience. Unfortunately, there are at least two situations in which C++ is a more suitable alternative to Java and C#: - Where performance is critical. Run time of C# code (using the faster .NET 2.0 runtime) can be as much as double the run time of a C++ version of the same algorithm. Try telling a large company that it must double the size of its compute farms so you can switch to a better programming language! Don't go there, sister. Come up with some reasonable tests before making a statement like that. Assembly code can be as much as a million times faster then the run time of a C++ version of the same algorithm. Bit useless, isn't it? Lets not forget that writing faster/more optimised code in c++ will be more complex and hence allow room for more errors then letting the c#/java runtime optimiser do the dirty work for us. However, I suspect that most security-critical programs do not fall into either of these categories, What? Cryptography rings a bell ... so C# or Java would indeed be a better choice than C++ for those programs. David Crocker, Escher Technologies Ltd. Consultancy, contracting and tools for dependable software development www.eschertech.com -- 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] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On 10/13/06, Craig E. Ward [EMAIL PROTECTED] wrote: At 10:03 AM -0400 10/12/06, ljknews wrote: At 9:20 AM -0400 10/12/06, Robert C. Seacord wrote: I'm also teaching a course at CMU in the spring on Secure Coding in C and C++. Is there participation on this list from the (hopefully larger number of) CMU instructors who are teaching people to use safer languages in the first place ? -- Larry Kilgallen I don't think saying use safer languages is a good way to say it. It would help conditions significantly if greater care were taken to match the choice of programming language to the problem to be solved or application to be created. If a language like C is most appropriate, then use it, just be sure to take the extra steps needed to develop it securely. The problem is so much the programming languages as it is the way they are used. Well, programming languages can go a long way to helping solve the problem, and it can be reasonably grey as to where to use what. Should I use php or ror? or python? or c#? I'd say there is a very appropriate and open space for nice secure languages to live and develop. Craig -- 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] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
On 10/12/06, Gadi Evron [EMAIL PROTECTED] wrote: So, how can we edit current basic programming college books to present secure code, a couple of words of the correct way of doing things, and a whole new chapter on secure coding (which may be redudndent?) How do we start? Some Whiley book for introduction to CS? Any volunteers to get this on the road? Secure programming is good programming. Most books teach good programming. People just don't care. Gadi. -- 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] Secure programming is NOT just good programming
On 10/13/06, David A. Wheeler [EMAIL PROTECTED] wrote: mikeiscool claimed: Secure programming is good programming. Most books teach good programming. I strongly disagree with you, on both counts. As is your right :) At the least, those who say they practice good programming practices, and books that say they teach good programming practices, are GROSSLY INADEQUATE for developing secure programs. Sure. First, Secure programming is good programming: Most people and organizations who claim that they perform good programming practices do NOT perform practices necessary for security. You could argue that therefore they aren't really doing good programming, but that doesn't help fix anything. That's not an argument against it. I believe it will help, anyway, if you can say to the public: this program is written badly instead of this program is written unsecurely. Almost everyone doesn't want to hear the second version. If they ask why, well you can explain. But keep it simple. And organizations STILL generally place features over security, and when there's a perceived conflict, security almost always loses... and they'll STILL say that they practice good programming practices (they just happen to correctly implement insecure programs). You can design an insecure program that is coded well, and hence only insecure in the ways you wish. You are mixing secure/good programming with secure/good design. Here are some practices you should typically be doing if you're worried about security, and note that many are typically NOT considered good programming by the general community of software developers: * You need to identify your threats that you'll counter (as requirements) * Design so that the threats are countered, e.g., mutually suspicious processes, small trusted computer base (TCB), etc. * Choose programming languages where you're less likely to have security flaws, and where you can't (e.g., must use C/C++), use extra security scanning tools and warning flags to reduce the risk. * Train on the specific common SECURITY failures of that language, so you can avoid them. (E.G., gets() is verbotin.) * Have peer reviews of the code, so that others can help find problems/vulnerabilities. * Test specifically for security properties, and use fuzz testing rigged to test for them. Few of these are done, particularly the first two. I'll concede that many open source software projects do peer reviews, but you really want ALL of these practices. Yep. Next, Most books teach good programming. Pooey, though I wish they did. Okay that was wishful thinking. I still find buffer overflows in examples inside books on C/C++. I know the first version of KR used scanf(...%s.) without noting that you could NEVER use this on untrusted input; I think the second edition used gets() without commenting on its security problems. A typical PHP book is littered with examples that are XSS disasters. Fair enough. The Software Engineering Body of Knowledge is supposed to summarize all you need to know to develop big projects.. yet it says essentially NOTHING about secure programming (it presumes that all programs are stand-alone, and never connect to an Internet or use data from an Internet - a ludicrous assumption). (P.S. I understand that it's being updated, hopefully it'll correct this.) I'd agree that check your inputs is a good programming practice, and is also critically important to secure programming. But it's not enough, and what people think of when you say check your inputs is VERY different when you talk to security-minded people vs. the general public. Yep. One well-known book (I think it was Joel on Software) has some nice suggestions, but strongly argues that you should accept data from anywhere and just run it (i.e., that you shouldn't treat data and code as something separate). It claimed that sandboxing is a waste of time, and not worthwhile, even when running code from arbitrary locations... just ask the user if it's okay or not (we know that users always say yes). When that author thinks check your inputs, he's thinking check the syntax - not prevent damage. This is NOT a matter of didn't implement it right - the program is working AS DESIGNED. These programs are SPECIALLY DESIGNED to be insecure. And this was strongly argued as a GOOD programming practice. Which is clearly wrong. People just don't care. There, unfortunately, we agree. Though there's hope for the future. --- David A. Wheeler -- 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] Google code search: good or bad?
good or bad, it's quite old. www.koders.com has been doing it for years. considering the source is available for anyone to download anyway, and investigate themselves, i don't see the big deal. the engines just let you search a whole bunch at once, and why would any one company/product care about that? if you want to target them, you do. if you just want to find a bug in any given open source product, then one of these may be slightly useful. if the main concern is that code can accidently get online, well that problem has been around forever and will never go away. better to expose it and have it dealt with, really. all in all, no big deal. jmho. -- mic On 10/12/06, Gary McGraw [EMAIL PROTECTED] wrote: Hi all, I spoke to Dennis Fisher about the Google code searching stuff that's been floating around on the list for a few weeks (since the original Bugle posting). Here's the resulting article: http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1 222898,00.html BTW, I wrote about this idea in my own article on darkreading back in August: http://www.darkreading.com/document.asp?doc_id=100643 What do you guys think about the capability? Is it good or is it bad? gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com ___ 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] Coding with errors in mind - a solution?
On 9/1/06, Pascal Meunier [EMAIL PROTECTED] wrote:
On 8/30/06 3:46 PM, Tim Hollebeek [EMAIL PROTECTED] wrote:
What you've proposed are exceptions. They do help (some) in separating
the normal logic from error handling, but:
(1) they often leave the job half done which has its own risks.
writing exception safe code can be more of a nightmare than error
checking.
I can't help noticing... In Ruby there's an ensure clause that allows you
to bring closure to half-done operations. Perhaps your point is that some
languages have poor exception support, just like some languages don't
provide safe string handling functions?
His point, I think, is that if you wrap a series of statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.
For example:
try {
openFile();
getData();
writeToFile();
setSomeFlag()
moveFile();
deleteTempThings();
} catch(Exception e){
...
}
Now obviously that's a statement that could be written far better, but
the point is that with the lazy/bad/accidental-bug-producing
programmer it might be common.
(2) in many languages, you can't retry or resume the faulting code.
Exceptions are really far less useful in this case.
See above. (Yes, Ruby supports retrying).
(3) you usually end up with some generic clean up code, which generally
hides more errors than it solves.
I don't think that's fair. Yes, you can write poor exception handling code,
but it's far easier to simply ignore or overlook errors or write poor error
handling code to the point where the error is effectively ignored (or
hidden) or the cause of the error becomes unidentifiable. Exceptions
allow me to reduce code duplication (and lower the chance of inconsistent
treatment and bugs), simplify the code (which makes it easier to understand
and therefore audit) as well as handle problems at an appropriate layer in
the code.
Exceptions simplify the code? I don't think so. They also don't reduce
code duplication [per se] you need to add extra functions, etc, to do
that.
I'm not saying that exceptions are always the best way to handle things, but
they can be part of good programming practices.
They _can_ be, but often aren't.
Pascal Meunier
-- 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] Forwarded: PHP encryption for the common man
On 7/26/06, Kenneth Van Wyk [EMAIL PROTECTED] wrote: FYI, I saw an interesting article today on IBM's web site detailing how to (and how NOT to) use encryption within PHP code. Those interested can find the article at: http://www-128.ibm.com/developerworks/library/os-php-encrypt/index.html?ca=drs- This doesn't seem like a _great_ article, for the 'common man', as it involves, at least in the last step, executing a binary with propsed input from the user (i.e. a username, or something) as command line parameters. It validates one (the 'msg' from the form), but not the others that may be adjusted to accept input as well. Not only is the binary ran, but it would imply that the script as executable permissions on at least that file, if not the entire directory, or even entire system. All of which are bad. It also recommends to use md5, which is totally broken as a secure hashing function and should not be used at all. Cheers, Ken -- 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
Sorry, but it is a fact. Yes, you can have provably correct code. Cost is approximately $20,000 per line of code. That is what the procedures required for correct code cost. Oh, and they are kind of super-linear, so one program of 200 lines costs more than 2 programs of 100 lines. Someone already pointed this out but your numbers here have no basis. Provide references or something, otherwise they are meaningless. This isn't as true and as wide spread as you make it sound. Consider, for example, SQL Injection. Assuming I do not upgrade my database, and do not change my code and server (i.e. do not change my environment at all), then if I have prevented this attack initially nothing new will come up to suddenly make it work. Indeed, consider SQL injection attacks. They didn't exist 5 years ago, Prove it. because no one had thought of them. Same with XSS bugs. Again prove it. I might say that they didn't exist at a given time because apps that were affected weren't widely deployed. Online BBS's are relatively new, and that, to my memory, was the first place for XSS bugs. What Dana is trying to tell you is that some time in the next year or so, someone is going to discover yet another of these major vulnerability classes that no one has thought of before. At that point, a lot of code that was thought to be reasonably secure suddenly is vulnerable. Right, but if your environment is unchanged and you've looked at all angles, then you will not be affected. Note that I'm not saying it's easy, but .. Not true; you can call other libraries happily and with confidence if you handle the case of them going all kinds of wrong. This also is false. Consider the JPG bug that badly 0wned Microsoft desktops a while back. It was a bug in an image processing library. You try to view an image by processing it with the library, and the result is that the attacker can execute arbitrary code in your process. That is pretty difficult to defensively program against. Why? 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
On 7/21/06, Florian Weimer [EMAIL PROTECTED] wrote: * 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. Really secure software should require _less_ user training, not more. -- 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
On 7/21/06, Dana Epp [EMAIL PROTECTED] wrote: 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. Why? Why accept this as a fact? It is not a fact. If you put procedures in place and appropriately review and test you can be confident. The weakest link here is the human factor, and people make mistakes. Yes they do. So help them to stop it by teaching and testing and reviewing. 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. This isn't as true and as wide spread as you make it sound. Consider, for example, SQL Injection. Assuming I do not upgrade my database, and do not change my code and server (i.e. do not change my environment at all), then if I have prevented this attack initially nothing new will come up to suddenly make it work. If the environment IS changed, however, then of course it's expected that the program should be reviewed and checked again. 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. Not true; you can call other libraries happily and with confidence if you handle the case of them going all kinds of wrong. 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. Yes, Much to learn. Like the fact that it _is_ reachable if you believe you can reach it. And, you know, study yoga and live in a cliff for a few years. Regards, Dana Epp [Microsoft Security MVP] http://silverstr.ufies.org/blog/ -- 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
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 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
