Re: [SC-L] Compilers
I have a better idead. Stop using C++. Jeeze. gem -Original Message- From: Robert C. Seacord [mailto:[EMAIL PROTECTED] Sent: Thu Dec 21 20:40:35 2006 To: McGovern, James F (HTSC, IT) Cc: Thomas Plum; Secure Coding Subject:Re: [SC-L] Compilers James, Response below. > I have been noodling the problem space of secure coding after > attending a wonderful class taught by Ken Van Wyk. I have been > casually checking out Fortify, Ounce Labs, etc and have a thought that > this stuff should really be part of the compiler and not a standalone > product. Understanding that folks do start companies to make up > deficiencies in what large vendors ignore, how far off base in my > thinking am I? Tom Plum (from Plum Hall, Inc.) is developing a solution called Safe/Secure C/C++ (SSCC) that might interest you (http://www.plumhall.com/sscc.html). SSCC incorporates static-analysis methods into the compiler as well adding as run-time protections schemes to eliminate buffer overflows as well as mitigate against other types of vulnerabilities. (I know that the claim seems exaggerated, but the approach seems quite sound and I have yet to identify a case that SSCC can not eliminate). Anyway, there is more information on his web site and I have cc'd Tom on this message in case you would like to contact him directly. rCs ___ 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. ___ 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 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] Compilers
James, Response below. > I have been noodling the problem space of secure coding after > attending a wonderful class taught by Ken Van Wyk. I have been > casually checking out Fortify, Ounce Labs, etc and have a thought that > this stuff should really be part of the compiler and not a standalone > product. Understanding that folks do start companies to make up > deficiencies in what large vendors ignore, how far off base in my > thinking am I? Tom Plum (from Plum Hall, Inc.) is developing a solution called Safe/Secure C/C++ (SSCC) that might interest you (http://www.plumhall.com/sscc.html). SSCC incorporates static-analysis methods into the compiler as well adding as run-time protections schemes to eliminate buffer overflows as well as mitigate against other types of vulnerabilities. (I know that the claim seems exaggerated, but the approach seems quite sound and I have yet to identify a case that SSCC can not eliminate). Anyway, there is more information on his web site and I have cc'd Tom on this message in case you would like to contact him directly. rCs ___ 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] Compilers
At 11:38 AM -0500 12/21/06, McGovern, James F (HTSC, IT) wrote: > This does beg another question of should the community be helping the > folks who design languages to build in security-oriented constructs that > we can leverage instead of waiting for after-the-fact find-it utilities? Language designers do what suits their purpose. Some language designers have security as their purpose. If your goal is to convince the other language designers they should take a different attitude, the best path is to patronize those languages that have taken security seriously. Today, very few language users are willing to do that. -- Larry Kilgallen ___ 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. ___
[SC-L] secure application development course
Katholieke Universiteit Leuven organizes an intensive course on secure application development for experienced software practitioners, in partnership with Solvay Business School and L-Sec (Leuven Security Excellence Consortium), from February 26th to March 2nd 2007. The course is aimed at software architects, designers, developers, testers and technical project managers and is limited to 25 places for optimal interaction. The world class instructors have wide-ranging experience in academia and industry and are experts in application security. They include prof. Bart Preneel who heads COSIC, the renowned crypto lab, prof. Frank Piessens of K.U.L. who pioneered teaching application security at university level, Ken van Wyk, co-founder of the CERT Coordination Center, prof. Dan Wallach of Rice University who is well-known for his seminal work on the Java sandbox and Danny De Cock, a COSIC researcher, whose web site is the foremost repository of technical information on the Belgian eID card. The course focuses on secure software engineering principles and techniques for countering threats and vulnerabilities in today's target environments. It provides participants with a thorough grounding in application security. The course takes place in the Groot Begijnhof in Leuven, Belgium, a UNESCO World Heritage site. Registration is on a first-come, first-served basis. For more information visit the web site: http://secappdev.org. -- Johan Peeters program director http://www.secappdev.org +32 16 649000 ___ 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] Compilers
"McGovern, James F \(HTSC, IT\)" > I have been noodling the problem space of secure coding after attending > a wonderful class taught by Ken Van Wyk. I have been casually checking > out Fortify, Ounce Labs, etc and have a thought that this stuff should > really be part of the compiler and not a standalone product. > Understanding that folks do start companies to make up deficiencies > in what large vendors ignore, how far off base in my thinking am I? You're on-track. Indeed, you can see little pieces of it happening. I'll use gcc as an example, because it's one of the most widely used C/C++ compilers in the world. In the last few years much has been added to gcc, including the ability to detect format string errors and many mechanisms to help counter buffer overflows (randomization, StackGuard & later IBM's ProPolice sort-of-reimplementation, etc.). I expect more detection and prevention mechanisms to go into gcc C/C++ compilers in the future. But I think you're not going far enough back. Compilers or interpreters are very much limited by the language (notation) they're trying to support. It's hideously hard to retrofit many kinds of detection into C/C++, because programs written in those notations just don't have enough information to easily determine if things are okay. Buffer overflows are an obvious example; they can't even OCCUR in most languages, but are rife in C/C++ because information about buffer size is not necessarily available to a buffer user (yes, I know about C++'s STL, but you don't HAVE to use it). Which is why separate tools are used -- the analysis work can be hideously hard. It's better to have a language (including its library) where the problem can't occur (e.g., because it's trivial to detect it) or is at least unlikely/hard (e.g., make the "easy" way the secure way). Java (and its clone C#) avoid many problems by DESIGN instead of happenstance, e.g., you can't (normally) have buffer overflows (in normal protected code they can't happen). Even stupid stuff like = vs. == mixing goes away (mostly). If a language is designed to make it EASY to do the right thing, the right thing is more likely to occur. PHP, especially old versions, is an obvious case in point. Old versions (where global_registers was true by default) are almost impossible to write secure software for. I will say that at least the PHP folks were willing to change their language when it was realized that their language's design made it nearly impossible to be secure. I wish they'd take more steps, but on the other hand, other language communities are unwilling to take even small steps to eliminate sharp edges from their languages. --- David A. Wheeler ___ 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] Compilers
It would be worth knowing more about the basis you use for drawing the conclusion, but if it's just the overlap between compilers and static analyzers represented by the abstract syntax tree, I don't think that's enough to warrant building one into the other (it might argue for having a shared parser, but I don't think parsers are hard enough to build to make that worthwhile). I would also suggest that looking for security weaknesses fits more into the unit testing part of development rather than the compiling part. As for "standalone," I think Jtest is built as an Eclipse plug-in; I don't know if you'd consider that standalone or not, but at least the developer doens't have to start up another shell to run it. Also, depending on the customer's organization, it might not be the developer who is running the security static analysis. I was talking with an organization that was thinking of having the security group run the static analysis, as part of the acceptance phase of an iteration. - Aaron From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Thursday, December 21, 2006 10:31 AM To: Secure Coding Subject: [SC-L] Compilers I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? *** ** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *** ** ___ 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] Compilers
On 21 Dec 2006, at 23:19, ljknews wrote: > > Isn't the whole basis of Spark a matter of adding proof statements in > the comments ? You can achieve very similar goals by using unit tests. Although the tests are not integrated into the code as tightly as something like Spark (or enforcing rules in the compiler), they are considered part of the source. IMO unit and integration testing are vastly underutilised for performing security tests which is a shame because all the infrastructure, tools and skills are there - developers (and security testers) just need to start implementing security tests in addition to the functional tests. [shameless plug] I wrote a paper about this for OWASP a few months back: http://www.corsaire.com/white-papers/060531-security-testing-web- applications-through-automated-software-tests.pdf -- Stephen de Vries Corsaire Ltd E-mail: [EMAIL PROTECTED] Tel:+44 1483 226014 Fax:+44 1483 226068 Web:http://www.corsaire.com -- CONFIDENTIALITY: This e-mail and any files transmitted with it are confidential and intended solely for the use of the recipient(s) only. Any review, retransmission, dissemination or other use of, or taking any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you have received this e-mail in error please notify the sender immediately and destroy the material whether stored on a computer or otherwise. -- DISCLAIMER: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Corsaire Limited, unless otherwise specifically stated. -- Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF Telephone: +44(0)1483-226000 Email:[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 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] Compilers
Once again though, using security-oriented constructs requires that the developers use them and use them correctly. Static code analysis tools (like Fortify) aren't after-the-fact, they should be inline during the process of development. If you can create a development process and environment of security you have won 90% of the war and the Klingons shall subside when the mighty static analysis ship sails into port. Now relying solely on a black box testing suite or a fuzzer, is just validating the code your attackers already know is weak. Don't get me wrong, I incorporate some fuzzing in our testing process, but this is only because its repeatable, automated, and it enables me to spend some time answering emails to interesting mailing lists. :) JS _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, James F (HTSC, IT) Sent: Thursday, December 21, 2006 8:38 AM To: Gunnar Peterson Cc: Secure Mailing List Subject: Re: [SC-L] Compilers Gunnar, I think the problem space of secure coding will never be pervasively solved if it relies on the licensing of tools for every developer on the planet. Folks have been conditioned to not pay for developer level tools and now use Eclipse, etc. Putting it only in the hands of a few folks may be useful or it may be futile, only time will tell. In terms of your analogy of using try/catch blocks, I would say the following: First, languages within the last ten years require you to use them and they are not optional for the developer to skip in many situations. Second, compilers actually check try/catch blocks which says that compilers can and do play an important role which the community should leverage vs avoid. This does beg another question of should the community be helping the folks who design languages to build in security-oriented constructs that we can leverage instead of waiting for after-the-fact find-it utilities? -Original Message- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 10:55 AM To: McGovern, James F (HTSC, IT); Secure Mailing List Subject: Re: [SC-L] Compilers Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for people to force developers to use Try...Catch blocks. -gp On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote: I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * _ ___ 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. ___ ___ 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] Compilers
Gunnar, I think the problem space of secure coding will never be pervasively solved if it relies on the licensing of tools for every developer on the planet. Folks have been conditioned to not pay for developer level tools and now use Eclipse, etc. Putting it only in the hands of a few folks may be useful or it may be futile, only time will tell. In terms of your analogy of using try/catch blocks, I would say the following: First, languages within the last ten years require you to use them and they are not optional for the developer to skip in many situations. Second, compilers actually check try/catch blocks which says that compilers can and do play an important role which the community should leverage vs avoid. This does beg another question of should the community be helping the folks who design languages to build in security-oriented constructs that we can leverage instead of waiting for after-the-fact find-it utilities? -Original Message- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 10:55 AM To: McGovern, James F (HTSC, IT); Secure Mailing List Subject: Re: [SC-L] Compilers Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for people to force developers to use Try...Catch blocks. -gp On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote: I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * _ ___ 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. ___ ___ 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] Compilers
At 10:30 AM -0500 12/21/06, McGovern, James F (HTSC, IT) wrote: > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary="_=_NextPart_001_01C72514.FE7A042C" > > I have been noodling the problem space of secure coding after attending a >wonderful class taught by Ken Van Wyk. I have been casually checking out >Fortify, Ounce Labs, etc and have a thought that this stuff should really >be part of the compiler and not a standalone product. Understanding that >folks do start companies to make up deficiencies in what large vendors >ignore, how far off base in my thinking am I? Isn't the whole basis of Spark a matter of adding proof statements in the comments ? I don't think the general compiler marketplace would go for that built-in to compilers. After all: 1. The Praxis implementation can be used with multiple compilers 2. The compiler market is so immature that some people are still using C, C++ and Java. But for the high-integrity market, Spark seems to fit the bill. -- Larry Kilgallen ___ 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] Compilers
Sure it should be built into the language, and I assume it will be eventually. Heck it only took 30 or 40 years for people to force developers to use Try...Catch blocks. -gp On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)" <[EMAIL PROTECTED]> wrote: > I have been noodling the problem space of secure coding after attending a > wonderful class taught by Ken Van Wyk. I have been casually checking out > Fortify, Ounce Labs, etc and have a thought that this stuff should really be > part of the compiler and not a standalone product. Understanding that folks do > start companies to make up deficiencies in what large vendors ignore, how far > off base in my thinking am I? > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > > > ___ > 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. > ___ ___ 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] Compilers
Integration of some of the static techniques found in tools like fortify into compilers does make sense. However, not all of the kinds of things should be put in the compiler (how many coders do you know that use the -Wall??!). So one use case for some of the knowledge would be compiler enforcement. Note that compilers are notorious for computing and then throwing out many things statically. They are designed to get their transformation business done, not to do real analysis. Still other things should be worked directly into the languages. C and C++ suck for security. And most importantly, rules tailored directly to the enterprise situation at hand require a platform like fortify. At cigital we have developed sets of custom rules for customers with great results. This cuts down false positives and makes it possible to enforce guidelines and standards that make sense for the business (think J2EE here). Bottom line...we need it all, and we need it now. gem P.S. Ken's course was co-designed by me and is based on my book. You might pick up a copy. company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -Original Message- From: McGovern, James F (HTSC, IT) [mailto:[EMAIL PROTECTED] Sent: Thu Dec 21 10:47:50 2006 To: Secure Coding Subject:[SC-L] Compilers I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * 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 is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] Compilers
I have been noodling the problem space of secure coding after attending a wonderful class taught by Ken Van Wyk. I have been casually checking out Fortify, Ounce Labs, etc and have a thought that this stuff should really be part of the compiler and not a standalone product. Understanding that folks do start companies to make up deficiencies in what large vendors ignore, how far off base in my thinking am I? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ 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. ___
