Re: [SC-L] How can we stop the spreading insecure coding examplesattraining classes, etc.?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Hollebeek Sent: 30 August 2006 18:23 To: 'Wall, Kevin'; SC-L@securecoding.org Subject: Re: [SC-L] How can we stop the spreading insecure coding examplesattraining classes, etc.? Really, the root of the problem is the fact that the simple version is short and easy to understand, and the secure version is five times longer and completely unreadable. While there always is some additional complexity inherent in a secure version, it is nowhere near as bad as current toolkits make it seem. No, the root cause of the problem is the use of inadequate notations so that we have to make secure versions 5 times as long in order to overcome those inadequacies. From my experience a typical secure SPARK implementation (which we have proved to be free from buffer overflow, numeric range violation etc.) is no longer or more complex than its simple version. Peter ** This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis High Integrity Systems Ltd (Praxis HIS). Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis HIS or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis HIS can be contacted at [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
Re: [SC-L] How can we stop the spreading insecure coding examplesattraining classes, etc.?
Tim Hollebeek writes... Really, the root of the problem is the fact that the simple version is short and easy to understand, and the secure version is five times longer and completely unreadable. While there always is some additional complexity inherent in a secure version, it is nowhere near as bad as current toolkits make it seem. I would say that secure versions that are *not* well thought out (particularly where security wasn't part of the original design) may tend to be FIVE times longer, but I don't think that's the typical case with code that is well designed. These security checks can be be modularized and reused like most other code. However, it may very well be that it is five times more difficult to develop the examples in the first place though, and THAT'S probably a major reason that we don't see it more often in example code. Demo code generally demonstrates some fairly powerful capability; the reason it is often short and sweet is because lots of effort has gone into making it possible to do useful things with minimal effort. Unfortunately, it is often the case that much less effort has gone into making it possible to do the same thing securely, so that code is quite a bit longer. You're right, if there was more of a pushback against broken demo code, maybe more effort would go into making it easy to do things securely, instead of insecurely. Well, I'm going to start pushing back when I can. Tomorrow I get the chance to bend the ear of some security folks from the Live.com site. I'm definitely going to be letting them know of my dissatisfaction wrt recent MS Atlas training and asking what I can do about it (other than completing the training evaluation). Every little bit helps. As Ed Reed pointed out, as an industry we did manage to get rid of computed gotos, spaghetti code, etc., so maybe there's hope. (But the pessimist in me says that it's probably easier to get people to _stop_ doing some poor practice than to start doing some good practice. I hope I'm wrong there.)-: For the moment, perhaps all we can do is try to publically shame them and bring about peer presure that way. I dunno. I think it's primarilly a people problem rather than simply a technological one, which is why it's so hard to solve. So while doing things like showing people secure coding idioms and secure design patterns (ala Marcus Schumacher) will only have minor impact until there is some major attitude change with both developers and upper management. I think part of the problem is that people have fallen into the trap of thinking that security is supposed to be hard and that checking all your errors is supposed to bloat your code by a factor of five, instead of wondering why library functions are designed in such a way that omitting complex logic around them fails in an insecure way. Secure code can be short and sweet, too, just not with most of the languages and tools that are currently popular. That's definitely a large part of it. Historically, most libraries haven't taken much of a security slant unless they've been crypto related. Most often, they first become well entrenched, and *then* there's an outpour of security vulnerabilites discovered as the library usage builds up a critical mass of usage. E.g., libc was this way. It wasn't until the Morris Internet worm in 1988 that people really started paying much attention to libc security issues. By that time libc was pretty much everywhere and what's worse, there wasn't really any viable alternative unless you wanted to roll your own. (That was long before GNU was prevalent.) And yes, buffer overflows were known very early, before Unix/C were widespread. But it was a different world then. This is an old, old problem. strcpy is insecure, and any code involving strncpy or a length check will be longer and/or more complex. But this is really just an artifact of the fact that buffers don't know their own length, making an additional check necessary. There is no reason why the secure version couldn't have been just as short and sweet, it just wasn't done. Or when strcpy() and its ilk were originally written, no one was concerned about buffer overflows...they were more concerned with program speed and size. The world changes. IMO, if you are still writing in a unsafe language like C or C++ when you don't really have to and are only using it because that's ALL YOU KNOW, then someone should take away your keyboard. Obviously there are legitimate reasons for using C/C++ and other pointy languages, but those reasons are holding less and less water every day. In the security class I've taught for the past 4.5 yrs or so, one of the things I tell my students is, if you have a choice, select a 'safe' language like Java or C# where you don't need to worry about buffer overflows or heap corruption. Not only is it safer, but it is also likely to improve your productivity. But at this point, I'd be (somewhat) okay with those showing
Re: [SC-L] How can we stop the spreading insecure codingexamplesattraining classes, etc.?
as an industry we did manage to get rid of computed gotos, spaghetti code, etc., so maybe there's hope. ever heard of exceptions? They're basically goto plus limited state. Spaghetti lives! gem company www.cigital.com podcast www.cigital.com/silverbullet 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
Re: [SC-L] How can we stop the spreading insecure codingexamplesattraining classes, etc.?
I take exception (haha!) at having them dismissed like this. It sounds like you encountered some badly written exception handling code. Error handling can also be really bad, where at every call layer the original error gets filtered or translated to a point where you just know something went wrong somewhere but have little idea what. Then you have to trace (yuck) and waste hours trying to identify the problem. I'll take limited state over no state any day (Ruby even tells you which line numbers of which files were involved). Pascal On 8/31/06 8:29 AM, Gary McGraw [EMAIL PROTECTED] wrote: as an industry we did manage to get rid of computed gotos, spaghetti code, etc., so maybe there's hope. ever heard of exceptions? They're basically goto plus limited state. Spaghetti lives! gem company www.cigital.com podcast www.cigital.com/silverbullet 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 ___ 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] CERT C Programming Language Secure Coding Standard
I would like to suggest an approach to solving Kevin's problem of How can we stop the spreading insecure coding examples at training classes, etc.? The CERT/CC has just deployed a new web site dedicated to developing secure coding standards for the C programming language, C++, and eventually other programming language. Each rule and recommendation contains at least one non-compliant coding example (the sort of thing you are likely to see in a poor training class) and at least one safe, secure compliant solution that shows how you can do the same thing safely. We are depending on the active involvement of the secure coding community (you) and relevant standards bodies to make this effort a success. I invite you to participate in this effort by reviewing content on the web site and providing comments, or by contributing new rules and recommendations for secure c coding. These can be sent to me directly or to secure-coding at cert dot com. I am attaching a press-release like article we wrote below to announce the effort. There is also a rationale section on the web site that provides more details as to what we are doing and why. Thanks, rCs --- The Carnegie Mellon Software Engineering Institute (SEI) CERT® Program has deployed a secure coding Web site at www.securecoding.cert.org to cooperate with the software development community in codifying a practical and effective set of secure coding practices for popular programming languages. These coding practices can then be used by software developers to eliminate vulnerabilities before software is operationally deployed. The purpose of this project is that the practices can be used by developers for professional development and as the basis for organizational coding standards supporting the quality of their products. Jeffrey Carpenter, manager of the CERT Coordination Center, says that the project is part of a larger secure coding initiative within the CERT/CC to eliminate dangerous coding practices that can result in exploitable software vulnerabilities. According to Carpenter, CERT is in a unique position to coordinate development of a set of secure coding practices because of its long history in analyzing and responding to software vulnerabilities. CERT's initial efforts are focused on the development of secure coding practices for the C and C++ programming languages. CERT senior vulnerability analyst Robert Seacord is leading the secure coding initiative. Seacord is a leading authority on secure coding, author of the book Secure Coding in C and C++ [Seacord 05], and technical expert for the ISO/IEC JTC1/SC22/WG14 international standardization working group for the programming language C. C and C++ were selected because a large percentage of critical infrastructures are developed and maintained using these programming languages, Seacord says. C and C++ are popular and viable languages although they have characteristics that make them prone to security flaws. Today's dependency on networked software systems has been matched by an increase in the number of attacks against governments, corporations, educational institutions, and individuals. These attacks result in the loss and compromise of sensitive data, system damage, lost productivity, and financial loss, says Seacord. To address this growing threat, the introduction of software vulnerabilities during development and ongoing maintenance must be significantly reduced, if not eliminated. CERT recognizes that there are a number of available resources, both online and in print, containing coding guidelines, best practices, suggestions, and tips. The Motor Industry Software Reliability Association (MISRA) developed guidelines for the use of the C language in critical systems [MISRA 04], and more recently the U.S. Department of Homeland Security launched its Build Security In web site (https://buildsecurityin.us-cert.gov) to promote the codification of practices and rules. These sources, however, do not provide a prescriptive set of secure coding practices that can be uniformly applied in the development of a software system. Without secure coding practices, software vulnerability reports are likely to continue on an upward trend, Seacord says. At CERT/CC, we have had nearly 4,000 vulnerabilities reported in the first half of 2006. To stop the threats, we need to develop secure software from the outset. The secure coding practices proposed by CERT are based on standard language versions as defined by official or de facto standards organizations such as ISO/IEC. CERT is not an internationally recognized standards body, but plans to work with organizations such as ISO/IEC to advance the state of the practice in secure coding. The ISO/IEC JTC1/SC22 WG14 international standardization working group for the programming language C, for example, has offered to provide direction in the development of the C language secure coding practices and to review and comment on drafts of the
[SC-L] (free) Software Security seminar next week in silicon valley
Hi all, I'm going to be giving a free seminar about software security along with Greg Rose from Qualcomm in Menlo Park on Thursday. More about the seminar here: http://www.cigital.com/news/cigital_seminar.pdf If you are in the area and you would like to attend, please drop me a quick note. gem company www.cigital.com podcast www.cigital.com/silverbullet 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
Re: [SC-L] Coding with errors in mind - a solution?
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? (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. I'm not saying that exceptions are always the best way to handle things, but they can be part of good programming practices. Pascal Meunier Tim Hollebeek Research Scientist Teknowledge, Corp. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael S Hines Sent: Wednesday, August 30, 2006 11:07 AM To: sc-l@securecoding.org Subject: [SC-L] Coding with errors in mind - a solution? a simple structure that provides for errors would go a long way... If - then - else - on error Do - end - on error Let x = y - on error Let x = function() on error etc... The problem is writing code without thinking of the possible errors that might arise. This forces you to think about the consequences of executing a command... Where 'error' is doing something intelligent when the original command doesn't work... Just a brainstorm... any merit to it? Mike Hines [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Reed (Aesec) Sent: Wednesday, August 30, 2006 1:17 PM To: sc-l@securecoding.org Subject: [SC-L] e: How can we stop the spreading insecure coding examples at, training classes, etc.? Message: 1 Date: Tue, 29 Aug 2006 15:48:17 -0400 From: [EMAIL PROTECTED] Subject: Re: [SC-L] How can we stop the spreading insecure coding examples at training classes, etc.? To: Wall, Kevin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: SC-L@securecoding.org Message-ID: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Quoting Wall, Kevin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : I think that this practice of leaving out the security details to just make the demo code short and sweet has got to stop. Or minimally, we have to make the code that people copy-and-paste from have all the proper security checks even if we don't cover them in training. If we're lucky, maybe they won't delete them when the re-use the code. I agree, and would like to extend it: security should be discussed *at the same time* that a topic is. Teaching security in a separate class, like I have been doing, reaches only a fraction of the audience, and reinforces an attitude of security as an afterthought, or security as an option. Comments in the code should explain (or refer to explanations of) why changing or deleting those lines is a bad idea. However, I'm afraid that it would irritate students, and make security the new grammar and spelling for which points are deducted from perfectly valid write-ups (i.e., it's my ideas that count, not how well I spell). The same used to be said about unstructured programming examples (computed gotos, spaghetti code, multiple entry and exit points from functions, etc). We got past it. We need a similar revolution in thought with regard to security, and some one to take the lead on providing clear, crisp examples of coding style that is more secure by its nature. I don't have one handy - but that's my wish. Ed ___ 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
Re: [SC-L] How can we stop the spreading insecure codingexamplesattraining classes, etc.?
ever heard of exceptions? They're basically goto plus limited state. Spaghetti lives! Not at all. Exceptions are not like gotos; in particular, an exception cannot be used to jump *into* a construct. The major problems with gotos are that they can be used to do branches that are downward or sideways in the code parse tree (versus structured constructs, which do such branches upward only). Exceptions are upward-only branches, and as a result don't have most of the problems gotos do. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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
