Re: [SC-L] Secure Coding Standards
An0n S3c, i see you have already found our site, but i should probably take this opportunity to provide a couple of updates. first of all, CERT has released the Java Secure Coding Standard in addition to existing secure coding standards for the C and C++ programming languages. CERT invites the Java community to participate in this effort by reviewing content in the Java space at https://www.securecoding.cert.org/confluence/display/java/CERT+Java+Secure+Coding+Standard and providing comments. second, The CERT C Secure Coding Standard is being published by Addison-Wesley and has already gone to the printer (it should be available in October). this book is the first official release of the standard and has the advantage over the wiki version that we are not changing it all the time, so you can actually implement it. 8^) anyway, you can read more (and preorder!) the book version here: http://www.amazon.com/Secure-Coding-Standard-Software-Engineering/dp/0321563212 another idea is to look a little further from strictly security related coding standards. another good C++ standard is JSF++ http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc. you may also want to look at the various MISRA standards. thanks, rCs I am looking for a comprehensive set of secure coding standards to implement into my dev organization. These standards should cover Java, Web, and C/C++ as well as guidelines for using features like encryption, authentication, SSO, SSL, etc. I am open to both publicly available standards as well as commercially available standards. So far, I found 1. www.securecoding.cert.org http://www.securecoding.cert.org/ - thanks to Robert C. Seacord, http://krvw.com/pipermail/sc-l/2008/001401.html 2. http://java.sun.com/security/seccodeguide.html 3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards 4. DHS Build Security In (kind of) - https://buildsecurityin.us-cert.gov/daisy/bsi/home.html 5. SANS Software Security Institute - http://www.sans-ssi.org/ 6. CERT Top 10 Secure Coding Practices - https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices 7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/ I would greatly appreciate any pointers to other links or to companies who have developed and sell these standards. Thanks in advance. An0n S3c. ___ 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. ___ -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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] GCC and pointer overflows [LWN.net]
Ken, Comment below. FYI, here's an interesting article (and follow-on discussions) about a recent bug in the GCC compiler collection. http://lwn.net/Articles/278137/ The bug, which has been documented in a CERT advisory, affects C code in which, under some circumstances, buffer bounds checking can be optimized out to produce binaries that are susceptible to buffer overflows. The article includes a couple examples that really help illustrate the issue -- very interesting reading, IMHO. Of course, many/most SC-Lers will no doubt jump on this as another example of why C is such a dangerous language to write (secure) code in, and that's fine. But, I see the issue at least a little differently: a compiler making decisions for the programmer and producing executable code that does not accurately conform to what the programmer coded. We've all heard of security-related optimizing issues for years, right? Well, here's a prime example of one in action. To be fair to gcc, the code in question is undefined behavior which means that the C standard gives the compiler lease to deal with the code in any manner they wish. This means that they do not need to diagnose the problem, generate object code, or generate correct code. This is a problem with the C language--the onus is on the developer to write conforming applications. The reason we dinged gcc in this case was because versions of the compiler prior to v 4.2 did generate object code in this case that was consistent with the user model (e.g., that adding a pointer to a integer could result in wrapping). Version 4.2 silently changed this behavior without providing a flag or option to diagnose the issue. They have since modified their compiler to warn on this issue, and once this version of the compiler is released we will update the vul note to recommend this version of the compiler be used. We are looking at this as a prototype for similar vulnerability notes dealing with erroneous or unexpected behavior in tools that can lead to the introduction of vulnerabilities in software, so I would be interested in feedback as to if vulnerability notes of this sort are of value. 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. ___
[SC-L] CERT C Secure Coding Standard - last call for reviewers
We would like to invite the community to review and comment on the current version of the CERT C Secure Coding Standard available online at www.securecoding.cert.org http://www.securecoding.cert.org before Version 1.0 is published. To comment, you can create an account on the Secure Coding wiki and post your comments there. Our intent is to complete major development of Version 1.0 by April 18, 2008, with the published version of the standard being available in September. Once Version 1.0 of the standard goes to the publisher, we will begin development of Version 2.0. That is, we will continue to maintain the wiki to further advance the working version of the CERT C Secure Coding Standard. The published 1.0 version will become the official version, until replaced by a future version. It is unlikely a subsequent version will be released any time in the next 2-3 years, so we would like to ensure that Version 1.0 will be a high quality product that will promote and encourage secure coding practices. Thanks for any help and assistance you have already provided and for any additional contribution you may make. There are currently 158 individuals who have contributed to the development of this standard, without whom this effort could not have succeeded. 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] Secure Coding Books
David, I like Secure Coding in C and C++ (http://www.cert.org/books/secure-coding/) The guy who wrote it is a bit of a jerk, but it has a lot of good technical information. Another book I like is The Art of Software Security Assessment http://www.amazon.com/gp/product/032126?ie=UTF8tag=taossa-20linkCode=as2camp=1789creative=9325creativeASIN=032126 (http://taossa.com/). rCs I've read several secure coding books in the past, and was wondering if anyone has recommendations for secure coding books (preferably from the last year or two). Thanks, David Lawson ___ 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. ___ -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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] Really dumb questions?
James, Bret- I agree with Bret that security and quality are inherently related (as well as many other system attributes). I think vendors (particularly sales guys) tend to reflect back to customers what they are hearing from other customers. So I think many customers go to these vendors asking for securitysolutions or looking for just general QA tools. Of course, there are also subsets of coding defects that are more high correlated with security vulnerabilities which is what a vendor often means by a security focus. rCs At 10:51 PM 29/08/2007, McGovern, James F (HTSC, IT) wrote: - So when a vendor says that they are focused on quality and not security, and vice versa what exactly does this mean? I don't have a great mental model of something that is a security concern that isn't a predictor of quality. Likewise, in terms of quality, other than producing metrics on things such as depth of inheritance, cyclomatic complexity, etc wouldn't bad numbers here at least be a predictor of a bad design and therefore warrant deeper inspection from a security perspective? My opinion is that security and quality are inherently related. Poor security indicates poor design, poor testing etc poor quality management tends to result in poor application security.. In fact two jobs ago I used this argument to implement security at a company who was extremely strong in quality (5% of the workforce belonged to the quality dept). I've also found that using quality tools such as FMECA etc for security assessments works very easily. Cheers Bret ___ 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. ___ -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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] University lecture on Sec Sw Eng online
In an off-line conversation, Holger suggested I put up a pointer to the undergraduate course in Secure Programming I offered this past spring in the School of Computer Science at CMU: https://www.securecoding.cert.org/confluence/display/sci/15392+Secure+Programming This course probably overlaps somewhat with Holger's Secure Coding lectures but also contains additional material. The course uses the Addison-Wesley book Secure Coding in C and C++ as a text. rCs I recently completed a lecture on secure software engineering, and I guess there a quite a few people on this list who could make use of some of the material, whether for their own presentations or simply for teaching themselves. The lecture was given at Kaiserslautern University of Technology as 12 lessons of 90 minutes (each comprising about 35 slides) in English; note that the accompanying student exercise problems are in German, however. The chapters (of varying length, as indicated by their mapping to lessons) are as follows: 01IT Security and Software Security 02Fundamental Notions and Definitions 03a Vulnerabilities and Attacks (Part 1) 03b Vulnerabilities and Attacks (Part 2) 04Security in the Software Development Process 05Security Requirements Elicitation 06Threat Analysis 07a Security in Architecture and Design (Part 1) 07b Security in Architecture and Design (Part 2) 08a Secure Coding (Part 1) 08b Secure Coding (Part 2) 09Quality Assurance 10, 11, 12 Process Models, Usability, and Conclusions You can find all the material at http://www.iese.fraunhofer.de/lectures/peine/materialcourse/ This was the first iteration of my first self-designed lecture; it is certainly not perfect yet (in fact I already have some improvements sketched for the next iteration, such as reorganizing the process material), so criticism is welcome. I know of few comparable lectures world-wide, i.e. university lectures covering security specifically from a software engineering viewpoint; so far, I'm aware of the lectures by Pascal Meunier at Purdue and by Dieter Gollmann at Hamburg-Harburg; if you know of any others, I'd be glad to hear about those, too. Kind regards from Germany, Holger Peine -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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] FW: What's the next tech problem to be solvedin softwaresecurity?
ljknews, Yes, it is virtually impossible to get a serious runtime error in an Ada program. For example: http://www.youtube.com/watch?v=kYUrqdUyEpI rCs At 9:51 PM +0100 6/9/07, David Crocker wrote: If instead we pay people to perform the more skilled tasks of establishing requirements and specifying the systems to meet them, and use computers to generate programs that meet the specifications, then such things as freedom from buffer overflow come free of charge. By freedom here, I don't mean the sort of freedom that comes in safe languages such as Ada and Java - in which the buffer overflow raises an exception, probably requiring a restart of the subsystem In my experience with Ada 83, the potential for buffer overflow is detected at compile time. When I get an unexpected runtime exception, it is almost always at the interface to another language. ___ 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] CFP: CERT Software, System and Information Security Cluster (HICSS-41)
. * HICSS will conduct double-blind reviews of each submitted paper. * Submit full paper according to detailed author instructions to be found on the HICSS web site (http://www.hicss.hawaii.edu/hicss_41/cfp_41.htm) by June 15. IMPORTANT 2007 DATES Abstracts are required for submission to this Cluster, or its minitracks. Please submit abstracts to the Cluster chairs by June 1st at [EMAIL PROTECTED] Please contact the Cluster Chairs for further guidance and indication of appropriate content at any time. * June 1 Authors should submit an abstract of their paper by this date to the Cluster Chairs ([EMAIL PROTECTED]). * June 15 Authors submit full papers by this date, following Author Instructions found on the HICSS web site. All papers will be submitted in double column publication format and limited to 10 pages including diagrams and references. HICSS papers undergo a double-blind review (June15 ? August15). Submit full paper according to detailed author instructions to be found on the HICSS web site (http://www.hicss.hawaii.edu/hicss_41/cfp_41.htm). * August 15 Acceptance notices are sent to Authors. At this time, at least one author of an accepted paper should begin fiscal and travel arrangements to attend the conference to present the paper. * September 15 Authors submit Final Version of papers following submission instructions posted on the HICSS web site. At least one author of each paper should register by this date with specific plans to attend the conference. * October 2 Papers without at least one registered author will be pulled from the publication process; authors will be notified. * December 1 Deadline to guarantee your hotel reservation at conference rate. Conference rate will be granted after this date, only if rooms are available. * December 15 There will be no refund for cancellation of registration after this date. CO-CHAIRS OF THE CSSIS CLUSTER Guido Schryen (RWTH Aachen University) Jason A. Rafail(CERT/CC) Address email to the Cluster Chairs to [EMAIL PROTECTED] CO-CHAIRS OF THE CSAS MINITRACK Jason A. Rafail (CERT/CC) Robert C. Seacord (CERT/CC) Dan Plakosh (CERT/CC) CO-CHAIRS of the CTERSC Minitrack Guido Schryen (RWTH Aachen University) Jose J. Gonzalez (Agder University College) Eliot H. Rich (University at Albany, State University of New York) PROGRAM COMMITTEE MEMBERS Julia Allen SEI, CMU Yue Chen University of Southern California Felix Freiling University of Mannheim Jose J. Gonzalez Agder University College Fred Long University of Wales, Aberystwyth Pascal Meunier Purdue University David Riley University of Wisconsin - La Crosse David Spooner Rensselaer Polytechnic Institute John Steven Cigital Kenneth Van Wyk KRvW Associates, LLC Carol Woody CERT, SEI, CMU -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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] temporary directories
David, Thanks for the explanation of mkdtemp(). I got confused reading the man page because I wasn't expecting the function to return char *, but I guess that makes sense. I wish that the C standard body would update the C library and add an exclusive create capability for fopen(), so that languages that build on fopen() can do so. Have you looked at TR 24731-1? The latest revision is n119 at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1199.pdf Section 6.5.2.1 defines the fopen_s function. I am planning on submitting a DR against this TR to add an exclusive create capability. There are also some new tmpfile_s() and tmpnam_s() functions although I have some issues with these as well. This doesn't work on at least old versions of NFS reliably, unfortunately. I believe that's been fixed, but I have not verified that. I also believe that it was fixed (in Version 3). 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. ___
[SC-L] temporary directories
I've seen advice here and there to use the mkdtemp() function to create temporary directories, for example: - Kris Kennaway email at http://lwn.net/2000/1221/a/sec-tmp.php3 recommends them - David Wheeler's Secure Programming for Linux and Unix HOWTO at http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html mentions it may not be a good idea if tmp cleaners are in use (but this sort of suggests maybe it is ok if they are not.) - HP 03 Tru64 UNIX Protecting Your System Against File Name Spoofing Attacks. January 2003. http://h30097.www3.hp.com/docs/wpapers/spoof_wp/symlink_external.pdf - etc. The mkdtemp() function generates a uniquely-named temporary directory from template. This function appears to work exactly like mktemp() works for files, except of course mktemp() has been widely discredited because of possible TOCTOU conditions and problems generating unique, unpredictable names. So my question is, why is mkdtemp() considered safe? Isn't it also susceptible to race conditions? Is there a reason why these race conditions are not at issue in this case? Or is it only considered safe because there is no alternative? Thanks, 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] re-writing college books - erm.. ahm...
Crispin, I think you may have over spoken below: Seeking perfect correctness as an approach to security is a fool's errand. Security is designing systems that can tolerate imperfect software. I could go along with achieving perfect correctness as an approach to security is a fool's belief but I believe the desire to achieve correctness is a prerequisite for security. More specifically, I have found that systematic schemes for providing software security (such as memory protection, canaries, etc.) are generally ineffective once a coding error (such as a buffer overflow) allows an attacker to penetrate the peripheral defense of code correctness. Given the current state of software security, I don't think any security best practice can abandoned and that defense-in-depth is a practical necessity. Also, back on the book topic, I recently heard of an older but successful book that did nothing but take examples from other books and show in detail how they were incorrect. Perhaps such a supplemental text could be developed for commonly used text books. 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
Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
Gadi, I sort of agree with mic that the problem is poor programming. My last manager liked to pick up C text books at random and point out all the vulnerabilities in the code examples that are being used to teach the next generation of programmers (how to write vulnerabilities). This community is perfect for this job. If the community is bored right now ;^) we are looking for community help to build up our knowledge of secure coding rules and recommendations for the C and C++ programming languages: www.securecoding.cert.org I'm also teaching a course at CMU in the spring on Secure Coding in C and C++. I'm hoping to take this material and incorporate it into the course. Once I get some experience teaching the material, I could help turn it into a college text. (I've written three books already, so I'm a proven threat. 8^) Thanks, rCs -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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 games
Gadi, Here are some searches from Derek Jones: The new Google source code search page has opened up some interesting research possibilities. How many instances of: if (...) ; are there out there (skip the first half dozen unusual macro uses)? http://www.google.com/codesearch?hl=enlr=q=++%5Csif%5C(%5B%5E)%5D*%5C)%3B+lang%3Ac%2B%2BbtnG=Search Security holes in PHP web applications: http://www.google.com/codesearch?hl=enlr=q=Where+%5C%24_POST+-addslashes+lang%3Aphp Back door passwords :-) http://www.google.com/codesearch?q=+%22backdoor+password 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] CERT C Programming Language Secure Coding Standard
of the informal CERT standard. According to WG14 convener John Benito, The secure coding standard is going in the correct direction, and I have confidence the final product will be useful to the community. CERT is also working with standards groups, such as the ISO/IEC working group on Guidance for Avoiding Vulnerabilities through Language Use (OWGV). While the ISO/IEC group is working on providing language-independent guidance, the CERT effort is working on developing and consolidating the language-specific guidance that provides the foundations for the ambitious goals of OWGV. Jim Moore, convener of OWGV, states that CERT's efforts in identifying and documenting secure coding practices for C and C++ will contribute to the standardization of these practices and advance the goals of the OWGV. Community Involvement The success of the secure coding standards depends largely on the active involvement of members of the secure software and C and C++ development communities. Rules and recommendations for each coding practice are solicited from the communities involved in the development and application of each programming language, including the formal or de facto standard bodies responsible for the documented standard. These rules and recommendations are edited by CERT senior members of the technical staff for content and style, and placed in Secure Coding Standards Web site for comment and review. The user community is invited to discuss and comment on the publicly posted content. Once a consensus develops that the rule or recommendation is appropriate and correct, the final rule is incorporated into the coding standard. Once practices are documented, tools can be developed or modified to verify compliance. Compliant software systems may then be certified as compliant by a properly authorized certification body. Seacord also envisions a training and development program to educate software professionals regarding the appropriate application of secure coding practices. The development of secure coding practices is a necessary step to stem the ever-increasing threat from software vulnerabilities. CERT's goal is that the enumeration of secure code practices will allow for a common set of criteria that can be used to measure and evaluate software development efforts. The public can review or comment on the existing content at the secure coding Web site or submit new ideas for secure coding practices by e-mailing [EMAIL PROTECTED] Robert Seacord can be reached at [EMAIL PROTECTED] *** [1] Seacord, R. Secure Coding in C and C++. Addison-Wesley, 2005. See http://www.cert.org/books/secure-coding for news and errata. [2] MISRA C: 2004 Guidelines for the use of the C language in Critical systems. MIRA Limited. Warsickshire, UK. October 2004. ISBN 0 9524156. -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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 integer library
Pascal, Nice. I'll mention it in my secure programming class this semester. I'd be interested in any exercises/labs based on it, appropriate for undergrads. ok. i'll be teaching an undergraduate elective on secure coding at CMU in the spring so i'll probably need to get to work on that soon. 8^) rCs -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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] managed string library
The SEI has published CMU/SEI-2006-TR-006 Specifications for Managed Strings and released a proof-of-concept implementation of the managed string library. The specification, source code for the library, and other resources related to managed strings are available for download from the CERT web site at: http://www.cert.org/secure-coding/managedstring.html The following is a brief summary of the managed string library: The managed string library was developed in response to the need for a string library that can improve the quality and security of newly developed C-language programs while eliminating obstacles to widespread adoption and possible standardization. As the name implies, the managed string library is based on a dynamic approach; memory is allocated and reallocated as required. This approach eliminates the possibility of unbounded copies, null-termination errors, and truncation by ensuring that there is always adequate space available for the resulting string (including the terminating null character). The one exception is if memory is exhausted; that is treated as an error condition. In this way, the managed string library accomplishes the goal of indicating either success or failure. The managed string library also protects against improper data sanitization by (optionally) ensuring that all characters in a string belong to a predefined set of safe characters. rCs -- Robert C. Seacord Senior Vulnerability Analyst CERT/CC Work: 412-268-7608 FAX: 412-268-6989 ___ 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] STL iterator vulnerabilities
Does anyone have any experience of specific examples of vulnerabilities resulting from the use of uninitialized or invalidated STL iterators or other STL related vulnerabilities? I'm doing some research for a new project (which I hope to announce here shortly). Thanks, 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
Re: [SC-L] HNS - Biggest X Window security hole since 2000
der Mouse wrote:
And, of course, nobody ever bothers to say just what the problem was.
Grrr. (Fortunately, I don't care, since I am running pre-X11R6.9.0
code, or I'd be trying to chase down the diff.)
Bad code:
/* First the options that are only allowed for root */
if (getuid() == 0 || geteuid != 0) {
if (!strcmp(argv[i], -modulepath))
Good code:
/* First the options that are only allowed for root */
if (getuid() == 0 || geteuid() != 0) {
if (!strcmp(argv[i], -modulepath))
The problem, of course, is that the address of geteuid is
always == true.
rCs
--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC
Work: 412-268-7608
FAX: 412-268-6989
___
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] Secure Software Architecture, Design, Implementation and Assurance CFP
Secure Software Architecture, Design, Implementation and Assurance CALL FOR PAPERS Fortieth Annual Hawai’i International Conference on System Sciences January 3 - 6, 2007 (Wednesday-Saturday) Hilton Waikoloa Village Resort and Spa on the Big Island 425 Waikoloa Beach Drive Waikoloa, Hawaii 96738 Tel: 1-808-886-1234Fax: 1-808-886-2900 www.hiltonwaikoloavillage.com HICSS conferences are devoted to advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Papers may be theoretical, conceptual, tutorial or descriptive in nature. Submissions undergo a double-blind peer referee process and those selected for presentation will be published in the Conference Proceedings. Additional detail may be found on HICSS primary web site: http://www.hicss.hawaii.edu Mirror site http://www.is.cityu.edu.hk/hicss/ SCOPE The Secure Software Architecture, Design, Implementation and Assurance minitrack focuses on the research and automation required to develop secure software systems that do not compromise other system properties such as performance or reliability. Current security engineering methods are demonstrably inadequate, as software vulnerabilities are currently being discovered at the rate of over 4,000 per year. These vulnerabilities are caused by software designs and implementations that do not adequately protect systems and by development practices that do not focus sufficiently on eliminating implementation defects that result in security flaws. An opportunity exists for systematic improvement that can lead to secure software architectures, designs, and implementations. The following topics are appropriate topics for research papers: • Static analysis tools and techniques for detecting security flaws and software vulnerabilities in source or binary code • Dynamic analysis tools for detecting security flaws and software vulnerabilities in source or binary code • Model checking tools for detecting security flaws and software vulnerabilities in software systems • Software architectures and designs for securing against denial-of-service attacks and other software exploits • Coding practices for improved security and secure library implementations • Computational security engineering • Other tools and techniques for reducing or eliminating vulnerabilities during development and maintenance CO-CHAIRS Sven Dietrich CERT[EMAIL PROTECTED] Daniel Plakosh CERT/CC [EMAIL PROTECTED] Robert C. Seacord CERT/CC [EMAIL PROTECTED] PROGRAM COMMITTEE Julia Allen SEI/CMU Hal Burch CERT/CC Brian Chess Fortify Software Bob Fleck Secure Software Michael Howard Microsoft Derek M. Jones Knowledge Software Ltd Alan Krassowski Symantec Fred Long University of Wales, Aberystwyth Tom Longstaff CERT Robert Martin MITRE Leon Moonen Delft University of Technology James W. Moore MITRE Samuel Redwine James Madison University David Riley University of Wisconsin - La Crosse John Steven Cigital Carol Woody CERT IMPORTANT DEADLINES Abstracts Authors are encouraged to contact Minitrack Chairs for guidance and indication of appropriate content. Manuscripts are not accepted based on abstracts. Full manuscripts must be submitted by June 15. June 15 Authors submit full manuscripts to the Peer Review System, following Author Instructions found on the HICSS web site (www.hicss.hawaii.edu). All manuscripts will be submitted in double column publication format and limited to 10 pages including diagrams and references. Since manuscripts will undergo a double-blind review, author names and affiliations must not be included on the original manuscript. This information will be collected later through the system. August 15 Acceptance notices are sent to Authors via the Peer Review System. September 15Authors submit Final Version of accepted papers following submission instructions on the Peer Review System web site. At least one author of each paper must register by this date with specific plans to attend the conference to present the paper. Early Registration fee applies. (General Registration fee applies Sept 16-Dec 15.) December 1 Deadline to guarantee your hotel room reservation at conference rate. December 15 Deadline to receive conference registration refund. Late registration fee applies. SUBMISSION INSTRUCTIONS • HICSS manuscripts must contain original material not previously published, nor currently submitted elsewhere. • HICSS will conduct double-blind reviews of each submitted manuscript. • Consult the conference website (www.hicss.hawaii.edu) for the listing and description of Minitracks for HICSS-40. • Contact the Minitrack Chair(s) by email for guidance and verification
