mikeiscool wrote: > 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. >>> >> 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. > 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.
>> 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. > Indeed, consider SQL injection attacks. They didn't exist 5 years ago, because no one had thought of them. Same with XSS bugs. Same with printf format string attacks. All of them are examples of processing user input without validation, but they are all really big classes of such, and they were discovered to occur in very large numbers in common code. 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. >> 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. > 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. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unaticipated problem Hacker: one who is adroit at pounding round pegs into square holes _______________________________________________ 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
