[SC-L] Secure Software Architecture, Design, Implementation and Assurance CFP

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

Re: [SC-L] HNS - Biggest X Window security hole since 2000

he 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

[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 _

[SC-L] managed string library

e 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/C

[SC-L] Dark Reading - CERT Seeks Secure Coding Input

Speaking of interesting articles from Dark Reading: http://www.darkreading.com/document.asp?doc_id=99807&WT.svl=news1_1 This is relatively early exposure for this effort. I am hoping to engage the folks on this list (and elsewhere) in this effort in the fall once the public wiki is stood up. I

[SC-L] secure integer library

ed the implementation. 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/list

Re: [SC-L] secure integer library

eed 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/

[SC-L] CERT C Programming Language Secure Coding Standard

ure-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 __

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=en&lr=&q=++%5C

[SC-L] Static code analysis via Google code search

people are having way too much fun with this: http://asert.arbornetworks.com/2006/10/static-code-analysis-using-google-code-search/ rCs ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/m

Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]

n 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 -- R

Re: [SC-L] Need a few slides/data on surging importance of security and source code security

re. I have > contributed to the community, too.) > > Thanks for your input, > 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.

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"

Re: [SC-L] re-writing college books - erm.. ahm...

Gadi, I feel like I've been here before, but I'll give it another shot anyway. > Okay, than let's make some progress: > 1. Where and who is currently involved with doing this? > 2. What are they doing? > 3. Can we use their experience to make it a larger success? > 4. How do we begin doing someth

Re: [SC-L] Why Shouldn't I use C++?

Ben, I would not go so far as to say never use C++. It is probably the most powerful and expressive commercially successful programming language available today and there are often good reasons to use the language. Secure programming in C++ is possible, but C++ itself is exceptionally complex, h

[SC-L] Integral Security article/library

I forgot to post notice to this list about an article published by Dr. Dobb's Journal on November 3rd that I wrote. It is available on-line at http://www.ddj.com/dept/security/193501774. If you attempt to download the secure integer library that we developed at CERT (http://www.cert.org/secure-c

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

[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/Se

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

[SC-L] CFP: CERT Software, System and Information Security Cluster (HICSS-41)

llation 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 Plakos

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 >> requir

Re: [SC-L] FW: What's the next tech problem to be solvedin softwaresecurity?

you from security/safety failures. rCs > At 9:16 AM -0400 6/10/07, Robert C. Seacord wrote: > >> ljknews, >> >> Yes, it is virtually impossible to get a serious runtime error in an Ada >> program. For example: >> >> http://www.youtube.com/watch?v

Re: [SC-L] University lecture on Sec Sw Eng online

rable 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 b

Re: [SC-L] Really dumb questions?

w.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-

Re: [SC-L] Programming language comparison?

Steven, A while back Hal Burch and I wrote an article on "Programming Language Format String Vulnerabilities" which is available here: http://www.ddj.com/security/197002914 In the article we looked at the potential consequences of format string vulnerabilities in Perl, PHP, Java, Python, and Rub

Re: [SC-L] Secure Coding Books

://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

[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 before Version 1.0 is published. To comment, you can create an account on the Secure Coding wiki

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 bou

Re: [SC-L] Secure Coding Standards

ication, 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/pipermai