[SC-L] free and open online secure coding in C course module

[Robert Seacord]

CERT has completed the development of an integer module for our "Secure Coding 
in C" course. A demo course set up at http://oli.web.cmu.edu Enter the course 
key: seccode

The course is open and free. If you want to use the course at your University, 
College, Corporation, or other organization you can register as an instructor 
and we can set up a course for you.

As always, I'm interested in your review and comments.

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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] [Article] Tracking and understanding security related defects

[robert]

Title:
Tracking and understanding security related defects: Useful data points for 
shaping your SDLC program   

Abstract:
"If you work in infosec for a large organization it can be difficult to easily 
track the state of every software level vulnerability throughout your various 
code bases. This is particularly true when groups outside of infosec such as 
the business unit, development, or QA are filing these defects and fail to loop 
in infosec (possibly because they don't know how!). Getting a grasp on how 
issues are being identified, and handled is essential for improving your orgs 
security program/s. By making a few changes to your bug tracking system it can 
become easier to understand the issues being discovered, effectiveness of 
certain testing tools and strategies, effectiveness of defenses, and can help 
improve processes addressing security related defects. "

Link:
http://www.qasec.com/2011/01/tips-for-tracking-security-related-defects-in-your-bugtracker.html
  
 
Regards,
- Robert Auger
http://www.webappsec.org/
http://www.qasec.com/
http://www.cgisecurity.com/
___
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

[SC-L] recent technical reports from the CERT Secure Coding Initiative

[Robert Seacord]

The Secure Coding Initiative at CERT has published several TRs recently.  Sorry 
I've been slow in sending out updates to the list.

Please let me know if you have any questions about any of these reports or are 
interested in collaborating with CERT to advance these projects.

Thanks,
rCs



Java Concurrency Guidelines

Fred Long, Dhruv Mohindra, Robert Seacord, & David Svoboda
CMU/SEI-2010-TR-015



An essential element of secure coding in the Java programming language is 
well-documented and enforceable coding standards. Coding standards encourage 
programmers to follow a uniform set of guidelines determined by the 
requirements of the project and organization, rather than by the programmer's 
familiarity or preference. Once established, these standards can be used as a 
metric to evaluate source code (using manual or automated processes).

The CERT Oracle Secure Coding Standard for Java provides guidelines for secure 
coding in the Java programming language. The goal of these guidelines is to 
eliminate insecure coding practices and undefined behaviors that can lead to 
exploitable vulnerabilities. Applying this standard will lead to higher quality 
systems that are robust and more resistant to attack.

This report documents the portion of those Java guidelines that are related to 
concurrency.



keywords: Java, concurrency, software security, coding standard, coding 
guidelines

cover date: May 2010

distribution: unlimited

editor: Pennie Walters (p...@sei.cmu.edu<mailto:p...@sei.cmu.edu>)
www.sei.cmu.edu/library/abstracts/reports/10tr015.cfm<http://www.sei.cmu.edu/library/abstracts/reports/10tr015.cfm>


As-If Infinitely Ranged Integer Model, Second Edition
Roger Dannenberg, Will Dormann, David Keaton, Thomas Plum, Robert C. Seacord, 
David Svoboda, Alex Volkovitsky, & Timothy Wilson

CMU/SEI-2010-TN-008



Integers represent a growing and underestimated source of vulnerabilities in C 
and C++ programs. This report presents the as-if infinitely ranged (AIR) 
integer model that provides a largely automated mechanism for eliminating 
integer overflow and truncation and other integral exceptional conditions. The 
AIR integer model either produces a value equivalent to that obtained using 
infinitely ranged integers or results in a runtime-constraint violation. 
Instrumented fuzz testing of libraries that have been compiled using a 
prototype AIR integer compiler has been effective in discovering 
vulnerabilities in software with low false positive and false negative rates.  
Furthermore, the runtime overhead of the AIR integer model is low enough for 
typical applications to enable it in deployed systems for additional runtime 
protection.



keywords: security, standardization, languages, verification, reliability, fuzz 
testing, software security, integral security, secure coding

cover date: April 2010

distribution: unlimited

editor: Pennie Walters (p...@sei.cmu.edu<mailto:p...@sei.cmu.edu>)
http://www.sei.cmu.edu/library/abstracts/reports/10tn008.cfm


Specifications for Managed Strings, Second Edition
Hal Burch, Fred Long, Raunak Rungta, Robert C. Seacord, & David Svoboda

CMU/SEI-2010-TR-018



This report describes a managed string library for the C programming language. 
Many software vulnerabilities in C programs result from the misuse of 
manipulation functions for standard C strings. Programming errors common to 
string-manipulation logic include buffer overflow, truncation errors, string 
termination errors, and improper data sanitization. The managed string library 
provides mechanisms to eliminate or mitigate these problems and improve system 
security. The CERT Program, which is part of the Carnegie Mellon Software 
Engineering Institute, provides a proof-of-concept implementation of the 
managed string library on its Secure Coding web pages.



keywords: string library, software security, C programming, runtime-constraint 
handling

cover date: May 2010

distribution: unlimited

editor: Paul Ruggiero (pruggi...@sei.cmu.edu<mailto:pruggi...@sei.cmu.edu>)
www.sei.cmu.edu/library/abstracts/reports/10tr018.cfm<http://www.sei.cmu.edu/library/abstracts/reports/10tr018.cfm>

Thanks,
rCs


Robert C. Seacord
Secure Coding Team Lead
CERT / Software Engineering Institute
Work: +1 412.268.7608
FAX:+1 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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] [WEB SECURITY] RE: I have not seen many people comment

[robert]

Jim,

The WASC Threat Classification v2 is a classification of attacks and 
weaknesses, not remediation's. This is  
stated in our definition. 

"The Threat Classification is an effort to classify the weaknesses, and attacks 
that can lead to the 
compromise of a website, its data, or its users."

I believe this thread was about constructive conversation on the owasp top ten, 
and the impact of using it in 
the real world, not about the WASC TCv2. However if you have specific 
suggestions please send them directly to 
me, or via the instructions within that document, we will listen to and 
evaluate *all* feedback once we kickoff 
the next update phase. 

Regards,
- Robert A.
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com/


> 
> My problem with WASC T2 is that it does not discuss remediation. Is this 
> coming soon?
> 
> - Jim
> 
> > Hello Matt,
> >
> > My only real concern is that the owasp top ten is now based on 'Risks' and 
> > has removed information/data disclosure/leakage.
> > Speaking as someone who has worked in a risk management team, I see the 
> > leakage of customer/sensitive data as one of the most
> > serious "Risks" that exist for a company, and it is something that is 
> > happening more and more. I brought this to the attention
> > of the Top Ten List back in November (see #5) 
> > https://lists.owasp.org/pipermail/owasp-topten/2009-November/000487.html 
> > and it
> > wasn't really addressed.
> >
> > If the top ten was based on attacks and weaknesses (or just 
> > vulnerabilities) rather than 'risks' then I could see the argument
> > for removal. Other than that, it is nice to see this document 
> > maturing/improving.
> >
> > Regarding your comment on open redirects I've seen these many times in the 
> > real worldand they ARE being used by individuals
> > to phish users. CSRF was used by the samy worm (not what I'd call a well 
> > organized motivated attacker as much as a Poc) in
> > combination with xss so I'd say it is used by both audiences (the abuse 
> > case is really application/functionality specific).
> >
> >
> > Regards,
> > - Robert A.
> > http://www.webappsec.org/
> > http://www.cgisecurity.com/
> > http://www.qasec.com/
> >
> >
> >
> >> --=_NextPart_000_02D7_01CAE13B.A677CE70
> >> Content-Type: multipart/alternative;
> >>boundary="=_NextPart_001_02D8_01CAE13B.A677CE70"
> >>
> >>
> >> --=_NextPart_001_02D8_01CAE13B.A677CE70
> >> Content-Type: text/plain;
> >>charset="us-ascii"
> >> Content-Transfer-Encoding: 7bit
> >>
> >> I have not seen many people comment on the new OWASP top Ten. What does
> >> every one think. I blogged about it from my perspective.  I am interested 
> >> in
> >> hearing about other people's experience with it.
> >>
> >>
> >>
> >> http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-to-owasp-to
> >> p-10-in.html
> >>
> >>
> >>
> >>
> >>
> >> Matt Parsons, MSM, CISSP
> >>
> >> 315-559-3588 Blackberry
> >>
> >> 817-294-3789 Home office
> >>
> >> "Do Good and Fear No Man"
> >>
> >> Fort Worth, Texas
> >>
> >> A.K.A The Keyboard Cowboy
> >>
> >>   <mailto:mparsons1...@gmail.com>  mailto:mparsons1...@gmail.com
> >>
> >>   <http://www.parsonsisconsulting.com>  http://www.parsonsisconsulting.com
> >>
> >>   <http://www.o2-ounceopen.com/o2-power-users/>
> >> http://www.o2-ounceopen.com/o2-power-users/
> >>
> >>   <http://www.linkedin.com/in/parsonsconsulting>
> >> http://www.linkedin.com/in/parsonsconsulting
> >>
> >>   <http://parsonsisconsulting.blogspot.com/>
> >> http://parsonsisconsulting.blogspot.com/
> >>
> >>   <http://www.vimeo.com/8939668>  http://www.vimeo.com/8939668
> >>
> >>   <http://twitter.com/parsonsmatt>  http://twitter.com/parsonsmatt
> >>
> >>
> >>
> >>
> >>
> >> 0_0_0_0_250_281_csupload_6117291
> >>
> >>
> >>
> >> untitled
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -

Re: [SC-L] [WEB SECURITY] RE: I have not seen many people comment on the new OWASP top Ten What does every one think I blogged about it fro

[robert]

Hello Matt,

My only real concern is that the owasp top ten is now based on 'Risks' and has 
removed information/data disclosure/leakage.   
Speaking as someone who has worked in a risk management team, I see the leakage 
of customer/sensitive data as one of the most
serious "Risks" that exist for a company, and it is something that is happening 
more and more. I brought this to the attention 
of the Top Ten List back in November (see #5) 
https://lists.owasp.org/pipermail/owasp-topten/2009-November/000487.html and it 
wasn't really addressed. 

If the top ten was based on attacks and weaknesses (or just vulnerabilities) 
rather than 'risks' then I could see the argument 
for removal. Other than that, it is nice to see this document 
maturing/improving.

Regarding your comment on open redirects I've seen these many times in the real 
worldand they ARE being used by individuals 
to phish users. CSRF was used by the samy worm (not what I'd call a well 
organized motivated attacker as much as a Poc) in 
combination with xss so I'd say it is used by both audiences (the abuse case is 
really application/functionality specific). 


Regards,
- Robert A.
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com/


> 
> --=_NextPart_000_02D7_01CAE13B.A677CE70
> Content-Type: multipart/alternative;
>   boundary="=_NextPart_001_02D8_01CAE13B.A677CE70"
> 
> 
> --=_NextPart_001_02D8_01CAE13B.A677CE70
> Content-Type: text/plain;
>   charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> I have not seen many people comment on the new OWASP top Ten. What does
> every one think. I blogged about it from my perspective.  I am interested in
> hearing about other people's experience with it.   
> 
>  
> 
> http://parsonsisconsulting.blogspot.com/2010/04/parsons-response-to-owasp-to
> p-10-in.html
> 
>  
> 
>  
> 
> Matt Parsons, MSM, CISSP
> 
> 315-559-3588 Blackberry
> 
> 817-294-3789 Home office 
> 
> "Do Good and Fear No Man"  
> 
> Fort Worth, Texas
> 
> A.K.A The Keyboard Cowboy
> 
>  <mailto:mparsons1...@gmail.com> mailto:mparsons1...@gmail.com
> 
>  <http://www.parsonsisconsulting.com> http://www.parsonsisconsulting.com
> 
>  <http://www.o2-ounceopen.com/o2-power-users/>
> http://www.o2-ounceopen.com/o2-power-users/
> 
>  <http://www.linkedin.com/in/parsonsconsulting>
> http://www.linkedin.com/in/parsonsconsulting
> 
>  <http://parsonsisconsulting.blogspot.com/>
> http://parsonsisconsulting.blogspot.com/
> 
>  <http://www.vimeo.com/8939668> http://www.vimeo.com/8939668
> 
>  <http://twitter.com/parsonsmatt> http://twitter.com/parsonsmatt
> 
>  
> 
>  
> 
> 0_0_0_0_250_281_csupload_6117291
> 
>  
> 
> untitled
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> --=_NextPart_001_02D8_01CAE13B.A677CE70
> Content-Type: text/html;
>   charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
>  xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"; =
> xmlns=3D"http://www.w3.org/TR/REC-html40";>
> 
> 
>  charset=3Dus-ascii">
> 
> 
> 
> <!--
>  /* Font Definitions */
>  @font-face
>   {font-family:Calibri;
>   panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
>   {font-family:Tahoma;
>   panose-1:2 11 6 4 3 5 4 4 2 4;}
>  /* Style Definitions */
>  p.MsoNormal, li.MsoNormal, div.MsoNormal
>   {margin:0in;
>   margin-bottom:.0001pt;
>   font-size:11.0pt;
>   font-family:"Calibri","sans-serif";}
> a:link, span.MsoHyperlink
>   {mso-style-priority:99;
>   color:blue;
>   text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
>   {mso-style-priority:99;
>   color:purple;
>   text-decoration:underline;}
> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
>   {mso-style-priority:99;
>   mso-style-link:"Balloon Text Char";
>   margin:0in;
>   margin-bottom:.0001pt;
>   font-size:8.0pt;
>   font-family:"Tahoma","sans-serif";}
> span.BalloonTextChar
>   {mso-style-name:"Balloon Text Char";
>   mso-style-priority:99;
>   mso-style-link:"Balloon Text";
>   font-family:"Tahoma","sans-serif";}
> span.EmailStyle19
>   {mso-style-type:personal;
>   font-family:"Calibri&qu

Re: [SC-L] working on java security help from experts

[Martin, Robert A.]

The Common Weakness Enumeration (CWE) has a "view" of issues that can 
occur in Java applications.


See: http://cwe.mitre.org/data/slices/660.html for a listing of all the 
details or: http://cwe.mitre.org/data/lists/660.html for a list of the 
items where the names are hyper-links to the content about them.


The entries include description, code examples, real world CVE examples 
of the issue in many cases, references and in most cases pointers to the 
attack patterns effective against the issue.


Bob

Matt Parsons wrote:

I am trying to become an expert in source code review in java application 
security.  Are there any experts on this list that are willing to share some of 
their knowledge?   I am reading Java Security by Scott Oaks and I am rereading 
all of the Sun Docs on java security.  Any help would be greatly appreciated.

Thanks,
Matt

Matt Parsons, MSM, CISSP
315-559-3588 Blackberry
817-294-3789 Home office
"Do Good and Fear No Man"
Fort Worth, Texas
A.K.A The Keyboard Cowboy
mailto:mparsons1...@gmail.com
http://www.parsonsisconsulting.com
http://www.o2-ounceopen.com/o2-power-users/
http://www.linkedin.com/in/parsonsconsulting
http://parsonsisconsulting.blogspot.com/
http://www.vimeo.com/8939668

[cid:image001.jpg@01CAD11E.CF635CA0]

[cid:image002.jpg@01CAD11E.CF635CA0]










___
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___

Re: [SC-L] Where Does Secure Coding Belong In the Curriculum?

[Robert Seacord]

Neil,

I teach two software security classes at Carnegie Mellon:

CS 15392 Secure Programming - Undergraduate Computer Science
https://www.securecoding.cert.org/confluence/display/sci/S08+15392+Secure+Programming
 

INI 14735  Secure Software Engineering - Graduate Course in Information 
Networking Institute (INI)

The INI materials are on our blackboard system and harder to share, but much of 
the material is the same as the undergraduate course.

If your (or anyone else) is interested in teaching this course (or portions of 
this course) at your college or university I would be happy to share the power 
point slides and other course materials with you.  However, because the SEI 
offers a 4 day version of this course to professional audiences (see 
http://www.sei.cmu.edu/products/courses/p63.html), as well as licensing this 
course to organizations to provide this training, this offer only applies to 
higher education and not to professional education.

Thanks,
rCs


Robert C. Seacord
Secure Coding Team Lead
CERT / Software Engineering Institute
Work: +1 412.268.7608
FAX:+1 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.
___

[SC-L] As-if Infinitely Ranged Integer Model

[Robert Seacord]

The Secure Coding Initiative at CERT has published a new Technical Note 
CMU/SEI-2009-TN-023 entitled "As-if Infinitely Ranged Integer Model". 

Abstract:

Integer overflow and wraparound are major causes of software vulnerabilities in 
the C and C++ programming languages. In this paper we present the as-if 
infinitely ranged (AIR) integer model, which provides a largely automated 
mechanism for eliminating integer overflow and integer truncation. The AIR 
integer model either produces a value equivalent to one that would have been 
obtained using infinitely ranged integers or results in a runtime constraint 
violation.  Unlike previous integer models, AIR integers do not require precise 
traps, and consequently do not break or inhibit most existing optimizations.

Authors:

David Keaton (self)
Thomas Plum (Plum Hall Inc.)
Robert C. Seacord (SEI/CERT)
David Svoboda (SEI/CERT)
Alex Volkovitsky (SEI/CERT)
Timothy Wilson (SEI/CERT)

A PDF Download of this paper is available at: 
http://www.sei.cmu.edu/publications/documents/09.reports/09tn023.html 

I would be interested in hearing your opinions on this work, either publically 
or privately.

We are planning on continuing this project, as described by the report.

Thanks,
rCs


----
Robert C. Seacord
Secure Coding Team Lead
CERT / Software Engineering Institute
Work: +1 412.268.7608
FAX:+1 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.
___

[SC-L] Article: 'Setting the appropriate security defect handling expectations in development and QA'

[robert]

Greetings,

I have just published the following article on handling application security 
defects (vulnerabilities) in development
and QA.

"If you've worked in information security you've likely had to report a 
security defect to development in an effort to 
remediate the issue. Depending on your organization and its culture this can be 
a rather difficult task. As an information 
security professional it is your job to detect, communicate, and see to the 
remediation of such issues in your company as 
these issues are discovered. Likely development is saying that they're to busy 
to fix the issue and that if they try fixing 
it they'll miss the deadline for their release, resulting in their group 
getting penalized (sometimes bonuses are tied to 
release cycles) or getting a negative comment on their performance review. In 
other situations development may just be 
stubborn requiring full proof of concept code before taking your security 
defect seriously. Development may even refer 
to infosec as a group that impedes progress by throwing bugs into the grinding 
gears of a given software release.

As an infosec professional you may feel at times helpless, or unable to do your 
job successfully due to the actions and 
stances of other groups. If you're currently in this situation there are a few 
things that you can do to get development 
either on the same page as you, or at least in agreement to the handling of 
these issues when they inevitably creep up."

Setting the appropriate security defect handling expectations in development 
and QA
http://www.qasec.com/2009/06/setting-the-appropriate-security-defect-handling-expectations-in-development-and-qa.html

Regards,
- Robert
http://www.webappsec.org/
http://www.cgisecurity.com/
http://www.qasec.com/

___
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] Insecure Java Code Snippets

[Robert Seacord]

Brad,

You can also look at The CERT Sun Microsystems Secure Coding Standard for Java 
at:

https://www.securecoding.cert.org/confluence/display/java/The+CERT+Sun+Microsystems+Secure+Coding+Standard+for+Java
 

Which has many examples of secure/insecure Java source code.

rCs

-Original Message-
From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
Behalf Of Brad Andrews
Sent: Wednesday, May 06, 2009 1:41 PM
To: sc-l@securecoding.org
Subject: [SC-L] Insecure Java Code Snippets



Does anyone know of a source of insecure Java snippets?  I would like to get 
some for a monthly meeting of leading technical people.  My idea was to have a 
"find the bug" like the old C-Lint ads.

Does anyone know of a source of something like this.

Brad
___
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] Julia Allen podcast on BSIMM

[Robert Seacord]

I might as well plug the podcast Julia did with me as well, "Mainstreaming 
Secure Coding Practices".  It is available at 
http://www.cert.org/podcast/show/20090317seacord.html   

rCs

-Original Message-
From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
Behalf Of Sammy Migues
Sent: Wednesday, April 01, 2009 12:09 PM
To: Secure Coding
Cc: Julia Allen
Subject: [SC-L] Julia Allen podcast on BSIMM

Hello everyone, 

Julia Allen, a senior researcher over at CERT, did a podcast with Gary, Brian, 
and me several weeks ago on the Building Security In Maturity Model (BSIMM).

You can listen to the results over at 
http://www.cert.org/podcast/show/20090331mcgraw.html. We talk a little about 
our mindset when starting the BSIMM research and our goals for the business 
uses.

Just as a reminder, BSIMM was released under Creative Commons license and is 
freely available at http://bsi-mm.com.

--Sammy.

___
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] Conditional Compile statements-- coding standards, and code review

[Robert Seacord]

Sean,

I think you would want to provide this guarantee through some sort of static 
assertion.  For example, if you want to ensure that text controlled by FRED is 
not included in a release build, you could include an #error preprocessor 
directive as part of the controlled text that will generate an error message 
for a release build:

#ifdef FRED
#  define MACRO(x) (x + 5)
#  ifdef NDEBUG
# error "FRED defined in release build"
#  endif
#endif

The idea here is that NDEBUG would be defined for a release build. If FRED and 
NDEBUG were defined in the same build it would result in a fatal compile-time 
diagnostic.

I'm not sure if there is a more elegant or widely deployed solution to this 
problem.

rCs

-Original Message-
From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
Behalf Of smurray1
Sent: Friday, February 13, 2009 10:49 AM
To: sc-l@securecoding.org
Subject: [SC-L] Conditional Compile statements-- coding standards, and code 
review

I am reviewing a QA team's procedures for code review.  I have an issue with 
conditional compile statements (#ifdef in the C world).  My issue is that it is 
very difficult to have complete confidence that a piece of code inside the 
condition (the "controlled text") does indeed not get compiled and included in 
the final executable.  The coding standards used by the organization are fairly 
rigorous, but there is no mention of prohibiting (or of even limiting) the used 
of conditional compile statements.  They are typically used for debug 
purposes-- that is, debug messages that get generated when the code is compiled 
for debugging and then are omitted in the production builds.  This is probably 
more of a correct code issue than a security issue,  but there are most 
definitely security implications. 

I am curious to hear people's thoughts on this.  Do most organizations prohibit 
(or at least limit) conditional compile statements?  If not, how is the 
"controlled text" inside conditional compile statements handled by code 
reviewers?  The QA procedures I am reviewing basically ignore them, since "They 
won't be in the production build", but I am 
very uncomfortable with that.   There are many ways in C to define the 
macro that controls the conditional compile (with #define statements, with 
compiler flags, etc).  It just seems very hard to verify that the ifdefs will 
work as planned in the final compile.

Thanks!!

Sean T Murray
___
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.
___

[SC-L] Application Security Vendors Need Help With Reporting

[robert]

Application Security Vendors Need Help With Reporting
http://www.cgisecurity.com/2009/02/application-security-vendors-need-help-with-reporting.html

Regards,
- Robert
http://www.cgisecurity.com/
http://www.webappsec.org/

___
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] The security industry needs to re-align its training expectations for QA

[robert]

I've posted a rant on training security to QA people.

The security industry needs to re-align its training expectations for QA
http://www.cgisecurity.com/2009/02/the-security-industry-needs-to-realign-its-training-expectations-for-qa.html

Regards,
- Robert 
http://www.cgisecurity.com/
http://www.webappsec.org/



Join WASC on IRC: irc.freenode.net #webappsec

___
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] Security metrics on flaws detected during architectural review?

[robert]

I've posted the following entry and I'm wondering what experiences people on 
this list have had. 

Security metrics on flaws detected during architectural review?
http://www.cgisecurity.com/2009/01/security-metrics-on-flaws-detected-during-architectural-review.html

Regards,
- Robert Auger
http://www.cgisecurity.com/
http://www.webappsec.org/

___
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] Robert Seacord on the CERT C Secure Coding Standard

[Robert Seacord]

informIT published an interview with me written by David Chisnall:

http://www.informit.com/articles/article.aspx?p=1315064

David asked some interesting questions about security and the future of the C 
programming language.

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] Language agnostic secure coding guidelines/standards?

[Robert Seacord]

Pete,

I think your best bet is the work being done by ISO/IEC JTC 1/SC 22/ WG 23 
Programming Language Vulnerabilities.  The website for this work is 
http://www.aitcnet.org/isai/.

The latest Editor's draft of PDTR 24772, prepared by John Benito, is N0138 
which can be found here:

http://www.aitcnet.org/isai/_Mtg_10/_Mtg_9/22-OWGV-N-0138/n0138.pdf

This document provides language independent guidance, with language specific 
annexes.  I think this comes closes to what you are looking for.

CERT has/is developing language specific standards for C, C++, and Java and are 
available online at www.securecoding.cert.org.  There is also a static version 
of the C standard which has been published by Addison-Wesley 
http://www.informit.com/store/product.aspx?isbn=0321563212 if you prefer your 
standards fixed instead of continually evolving.  ;^)

Our Java Secure Coding standard is being developed collaboratively with Sun 
Microsystems.  Eventually, I'll probably get an announcement out to that effect.

Thanks,
rCs

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Werner
Sent: Wednesday, November 12, 2008 7:22 PM
To: Secure Coding
Subject: [SC-L] Language agnostic secure coding guidelines/standards?

Hi all

I've been tasked with developing a secure coding standard for my employer. This 
will be a policy tool used to get developers to fix issues in their code after 
an audit, and also hopefully be of use to developers as they work to ensure 
they are compliant. The kicker is it needs to cover things ranging from cobol 
running on a mainframe, in house network monitoring software in c and perl 
through to web and desktop applications in java or .net.

I've been doing some searching to see if there is anything similar online, but 
everything i've found is mostly focussed on web applications or 
language/platform specific. Does anyone know of something that may be what I'm 
looking for?

It's basically going to be a checklist where every item will be something that 
can be audited, and the things that aren't relevant to a given application can 
be ignored. The broad sections I have so far
are:

Input/Output handling
Session Control and Management
Memory allocation and Management
Authentication Management
Authorisation Management
Data Protection
Logging and Auditing
Application Errors and Exceptions

Thanks in advance
Pete
___
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.
___

[SC-L] The CERT C Secure Coding Standard

[Robert Seacord]

The CERT C Secure Coding Standard has been published by Addison-Wesley.  More 
information is available at:

http://www.informit.com/store/product.aspx?isbn=0321563212

Thanks to all the "lurkers" on SC-L who helped us develop and review the 
content.

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] Secure Coding Standards

[Robert Martin]

As a compliment to coding standards you may want to consider using the 
Common Weakness Enumeration (CWE) as a target list of coding, design and 
implementation issues you are trying to minimize through use of those 
coding standards.

Using the CWEs can also help you to drive and correlate your test 
program into a cross checking of the issues you care about to assure 
yourself that they were actually addressed by your development 
standards.  Many of the testing approaches, whether they be from manual 
reviews, penetration testing/black box testing, or from white box 
testing/code assessments are easily correlated with CWEs either because 
the vendors are already tagging their finding with CWEs or because your 
testers can easily match their testing to the CWEs that their testing 
uncover.

Several large commercial development vendors are using CWE as a 
framework for targeting and tracking their application security reviews 
both as a way of articulating their goals about which kinds of issues 
they want to address as well as a way to document and track their progress.

Many of the coding standards efforts you listed, as well as the OWASP 
efforts, have already mapped (or are in the process of mapping) their 
coding standards/guidance to the CWEs that the individual rules address.

Regards,

Bob

anon sec wrote:
> 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 - 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.
> ___
___
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 Standards

[Robert C. Seacord]

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]

[Robert C. Seacord]

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

Re: [SC-L] Secure Development World ?

[Robert A. Martin]

Yes it is cancelled.


At 1:13 AM -0500 3/14/08, Gadi Evron wrote:
>I am trying to understand if this conference is cancelled or not?
>___
>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.
___

[SC-L] CERT C Secure Coding Standard - last call for reviewers

[Robert C. Seacord]

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

[Robert C. Seacord]

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=UTF8&tag=taossa-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=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] Programming language comparison?

[Robert C. Seacord]

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 Ruby programs.

Sorry, we didn't write anything about Ada.  ;^)

rCs

> On Mon, 4 Feb 2008, ljknews wrote:
>
>   
>>> ("%s" to fill up disk or memory, anybody?), so it's marked with
>>> "All" and it's not in the C-specific view, even though there's a heavy
>>> concentration of format strings in C/C++.
>>>   
>> It is marked as "All" ?
>>
>> What is the construct in Ada that has such a risk ?
>> 
>
> H, I don't see any, but then again I don't know Ada.  Is there no
> equivalent to format strings in Ada?  No library support for it?
>
> Your question actually highlights the point I was trying to make - in CWE,
> we don't yet have a way of specifying language families, such as "any
> language that directly supports format strings," or "any language with
> dynamic evaluation."
>
> - Steve
> ___
> 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] Programming language comparison?

[Robert A. Martin]

Hi Vincent,

While not a overview, you can find language specific weaknesses for 
C, Java, C++, and PHP on the "Other Views" page of the Common 
Weakness Enumeration (CWE) Project (see 
http://cwe.mitre.org/data/other.html).

The "List" items give the names of the issues, the "Slice" gives a 
concatenated set of the write-ups of those items, and the "XML" will 
give you a concatenated extract of the XML for those items versus 
hunting for them in the complete XML for CWE.

These aren't specific to web application issues so there will be some 
pruning of the list for your purposes.  One way to focus the list 
would be to correlate them with the CWEs listed in the OWASP Top 10 
as a start, which is another list on the above page that has 24 items 
listed but some of them are not language specific so they would be in 
addition to the others.

The above lists include 56 for C, Java has 70, C++ has 58, and PHP has 10.

You still need to add to that issues that apply to all languages 
versus these lists of language specific weaknesses and C and C++ have 
significant overlap given their relationship.

Regards,

Bob Martin
CWE Project Leader
MITRE Corporation

P.S. Comments and suggestions for new items, clarifications, or 
additional examples are welcome for this community effort either 
directly to [EMAIL PROTECTED] or through the cwe-research-list which you 
can sign-up for on the site.

At 1:16 PM +0100 2/4/08, Vincent Verhagen wrote:
>Hi all,
>
>I was referred to this list by a fellow security consultant for this
>specific question. Please forgive me if this is the wrong forum :)
>
>We're in the process of creating a kind of handbook for third parties
>that develop web applications for us.
>One (quite extensive, I'm happy to report) chapter will be about
>security and for that I'm looking for a comparison of common
>programming/scripting languages (PHP, C variants, JAVA, etc) their
>specific risks and why or why not to use them.
>Has anyone created such an overview I could use as a basis to work from?
>
>Thanks in advance!
>
>Vincent Verhagen
>Simac ICT Netherlands
>
>___
>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] Insecure Software Costs US $180B per Year - Application and

[robert]

I think many companies are working on making their code more secure however 
without some sort of 
penality to the business the others aren't going to invest in security. This in 
particular is why
I like what PCI has done (as an example) enforcing 'some' bare 
requirements/penalties for not doing
While it isn't perfect it's something.

I've spoken with a few organizations debating penalizing a developer 
financially if 
they have vulnerabilities in their code. It is actually pretty difficult to 
enforce
without the proper training/policies/procedures in place. I think if a tax 
existed 
this would force companies to develop these sorts of programs since it will 
most likely
be less expensive than paying the fine. 

My $1.50

Regards,
 - Robert Auger
http://www.webappsec.org/
http://www.cgisecurity.com/


> 
> 
> --===1159861409==
> Content-Type: multipart/signed; boundary=Apple-Mail-774--974102641; 
> micalg=sha1;
>   protocol="application/pkcs7-signature"
> 
> 
> --Apple-Mail-774--974102641
> Content-Type: text/plain;
>   charset=US-ASCII;
>   format=flowed;
>   delsp=yes
> Content-Transfer-Encoding: 7bit
> 
> FYI, there's a provocative article over on Dark Reading today.
> 
> http://www.darkreading.com/document.asp?doc_id=140184
> 
> The article quotes David Rice, who has a book out called   
> "Geekconomics: The Real Cost of Insecure Software".  In it, he tried  
> to quantify how much insecure software costs the public and, more  
> controversially, proposes a "vulnerability tax" on software  
> developers.  He believes such a tax would result in more secure  
> software.
> 
> IMHO, if all developers paid the tax, then I can't see it resulting in  
> anything other than more expensive software...  Perhaps I'm just  
> missing something, though.
> 
> Cheers,
> 
> Ken
> 
> -
> Kenneth R. van Wyk
> SC-L Moderator
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 
> --Apple-Mail-774--974102641
> Content-Disposition: attachment;
>   filename=smime.p7s
> Content-Type: application/pkcs7-signature;
>   name=smime.p7s
> Content-Transfer-Encoding: base64
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGdjCCAy8w
> ggKYoAMCAQICEE3TNKjT6vVPziZ4GZOH6N4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
> JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
> ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkxNTEzMzAxM1oXDTA4MDkxNDEzMzAx
> M1owgYoxEDAOBgNVBAQTB1ZhbiBXeWsxGDAWBgNVBCoTD0tlbm5ldGggUmljaGFyZDEgMB4GA1UE
> AxMXS2VubmV0aCBSaWNoYXJkIFZhbiBXeWsxGzAZBgkqhkiG9w0BCQEWDGtlbkBLUnZXLmNvbTEd
> MBsGCSqGSIb3DQEJARYOa2VuQHZhbnd5ay5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
> AoIBAQCqSxE6IaWzPYQK1MHK/5vFDNb7GmfI/WVjnBVDvyg2wC0EI1zhMGCRJtE78wPRshTg7kC5
> B8W2qNBIxRO8bkU3+Qw8ZRFjPz8EKDoxJuK6byfip64h5Q/HcL6JWNPRrHZQXwpEisehEgytMOJs
> JAoLzHUqi2zVz6Wq+NDhtmOIlegvnlcLiHY+IxZaK4bLe/p3717OtswZtJ+xQUS5J9DUf99PIR8q
> DWqt/fFBqhQ9a2zewPH/+Jrwnhl/2WdkCWBEn0kkz9J77hNVe7O0NAKGTirWkU3JKY39wCjb7pf2
> 0TNtoFvfj6oTTOwEdvIZkm6C/HMCf4Cwpc+zlLG6VhzlAgMBAAGjOTA3MCcGA1UdEQQgMB6BDGtl
> bkBLUnZXLmNvbYEOa2VuQHZhbnd5ay5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
> gQC7cfuLAK0R/H9LyvtBl4+8wt64B7eyTdQDQTyRUyH1IfJAPgXcG8edBPV/3ff6LOIf5bI0MBjF
> HjyavBM8532SVgzs+aadJ3gA8OFDnAAcA8lL0vgx1UJATWLneTxNDz5cauUdTpUAckw1V6tQ/erB
> a2BBcLPSdoT9P2B90LMPQDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNV
> BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
> ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2
> aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ
> ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYy
> MzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
> dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkq
> hkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6
> YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+
> B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
> CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ
> ZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE
> AxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+s
> vsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx
> VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQ
> MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
> KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD

Re: [SC-L] Really dumb questions?

[Robert C. Seacord]

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 "security"solutions 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

[Robert C. Seacord]

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?

[Robert C. Seacord]

The Ariane 5 disaster was due to a variety of software development
failures:  process, reuse, design, and coding.  the coding error was an
uncaught exception resulting from a floating point to integer conversion
error. 

My only point was that choice of language does not in and of itself
protect 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=kYUrqdUyEpI
>> 
>
> It amazes me that someone in a discussion of software security would point
> to a page that requires Javascript to be viewed.
>
> But I see the topic of the page was Ariane 5, a well known case of running
> software in an environment other than that specified in the design of the
> software.
>
> That is a management issue - my comments were about buffer overflows,
> as were the comments of David Crocker which I quoted.  If you have
> secret knowledge that the Ariane 5 failure was related to buffer
> overflows, please share it.
>
> Not reading what was going on, in fact, was the cause of the Ariene 5
> failure.
>
>   
>>> 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.
___

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

[Robert C. Seacord]

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)

[Robert C. Seacord]

te content.

* 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

[Robert C. Seacord]

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

[Robert C. Seacord]

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] Compilers

[Robert C. Seacord]

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

[SC-L] Integral Security article/library

[Robert C. Seacord]

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-coding/IntegerLib.zip), please use
Mozilla for the download.  There are reports that downloading with IE
causes the file to be corrupted, for reasons I don't currently understand.

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] Why Shouldn't I use C++?

[Robert C. Seacord]

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, has many idiosyncrasies, and as a result it is very easy to
make mistakes in the language.  Because of these factors, many C++
experts recommend an idiomatic approach to C++ where basically you reuse
 snippets of code that do something akin to what you are after.  The
message here, of course, is that you are likely to mess up if you write
some "new code" which has not been thoroughly considered by a panel of
experts for many years. 8^)

> If you use the STL containers and follow basic good
> programming practices of C++ instead of using C-Arrays and pointer
> arithmetic then the unsafe C features are no longer an issue?

See
https://www.securecoding.cert.org/confluence/display/cplusplus/13.+STL+%28STL%29
for common security flaws involving the STL

See
https://www.securecoding.cert.org/confluence/display/cplusplus/10.+Basic+string+class+%28BSC%29

for common security flaws involving basic_string (which also functions
as an STL sequence container)

Integer related security problems are basically the same for both C and C++.

> C and C++ are very different. Using C++ like C is arguable unsafe, but when
> it's used as it was intended can't C++ too be considered for secure
> programming?

I'll agree with you that using C++ in an idiomatic fashion is safer than
  using it like C.  One of the things you will note through the
www.securecoding.cert.org web site is that many of the problems for C
programming language also exist for C++, but the solutions are different
because C++ offers better/different options.  But you need to know to
use these, you have to be aware of the new problems that C++ brings, and
you often need to use C features to interact with existing libraries.

Hope this (partial) explanation helps somewhat.

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 - erm.. ahm...

[Robert C. Seacord]

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 something large-scale?

The Secure Coding Initiative at CERT has a web site at
www.securecoding.cert.org.  The purpose of this site is to collect
secure coding recommendations and rules for various programming
languages.  Our initial focus has been C and C++, but we are willing and
interested in expanding this effort to other programming languages
provided that we can find someone to manage the efforts.

The C and C++ material on the site will be used as supplemental material
to the Addison-Wesley book "Secure Coding in C and C++" in a "Secure
Programming" course I am teaching this Spring at CMU (so it is being
used to teach, as well as being a commercial and government resource).
I am also working with other instructors at other educational
institutions to develop secure coding curriculum.

We have had significant community effort in the development of these
secure coding standard practices so far, but we can use all the help we
can get.  If you would like to get involved, go the sight, sign up, and
start reviewing the material.  If you are qualified and would like to
edit the material directly, send me email and I will grant you edit
permissions.

I think having a body of knowledge that identifies insecure coding
practices and provides secure alternatives is a good first start, and
not as easy as it sounds.

-

I also had another thought about improving the quality of code examples
in texts.  I know my publisher (Addison-Wesley), and I'm sure others,
are very concerned about quality.  I could ask my editor if they would
be willing to make sure that someone with a security background reviewed
any new programming texts.  If we can come up with a list of subject
matter experts willing to review new texts, I'm guessing they would be
very happy to have our feedback.

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 - erm.. ahm...

[Robert C. Seacord]

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] Need a few slides/data on surging importance of security and source code security

[Robert C. Seacord]

Holger,

There are a bunch of slide sets on the CERT web site at:

http://www.cert.org/nav/present.html

The one labeled "Home Computer and Internet User Security (ppt)" might
be close to what you need.

I have some slide sets up there as well, but my stuff is too detailed
for a management audience.

rCs



> I am sure that quite a few of you already have done or know
> who has done this non-technical, "mundane" job: I need a few
> slides with data (e.g. numbers, or maybe historic examples) to 
> convince a management-level audience of a manufacturer of networked 
> appliances who has only a dim view of security of two things:
> 
> - security is a problem for anybody developing software running 
>   on networked hardware, and it is a rapidly growing problem with
>   a clear economic impact
> 
> - a large part of vulnerabilities stems from bad coding practices,
>   and there are companies that actively and successfully combat this
> 
> Pointers to relevant web pages would be nearly as nice as finished
> Powerpoint slides.
> 
> (Aside: You shouldn't view my request like that of a student asking for
> someone to steal his homework from: Everyone in our community needs 
> such data in some form or other at some time, and we should all
> contribute
> to making everyone in the community look as good as possible in this
> respect in, to advance our common cause of more secure software. 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.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]

[Robert C. Seacord]

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

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

[Robert C. Seacord]

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/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] Google code search games

[Robert C. Seacord]

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=++%5Csif%5C(%5B%5E)%5D*%5C)%3B+lang%3Ac%2B%2B&btnG=Search


Security holes in PHP web applications:

http://www.google.com/codesearch?hl=en&lr=&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

[Robert C. Seacord]

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 dire

Re: [SC-L] secure integer library

[Robert C. Seacord]

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] secure integer library

[Robert C. Seacord]

The CERT/CC has released a beta version of a secure integer library for
the C Programming Language.  The library is available for download from
the CERT/CC Secure Coding Initiative web page at:
http://www.cert.org/secure-coding/

The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

Functions have been provided for all integer operations subject to
overflow such as addition, subtraction, multiplication, division, unary
negation, etc.) for int, long, long long, and size_t integers.  The
following example illustrates how the library can be used to add two
signed long integer values:

long retsl, xsl, ysl;
xsl = LONG_MAX;
ysl = 0;
retsl = addsl(xsl,ysl);

For short integer types (char and short) it is necessary to truncate the
result of the addition using one of the safe conversion functions
provided, for example:

char retsc, xsc, ysc;
xsc = SCHAR_MAX;
ysc = 0;
retsc = si2sc(addsi(xsc, ysc));

For error handling, the secure integer library uses the mechanism for
Runtime-constraint handling defined by TR 24731 "Specification for
Safer, More Secure C Library Functions" available at:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

The implementation uses the high performance algorithms defined by Henry
S. Warren in the book "Hacker's Delight".

For more information on vulnerabilities and other problems resulting
from the incorrect use of integers in C and C++ please read Chapter 5 of
"Secure Coding in C and C++" which is available as a free download from
the CERT web site:

http://www.cert.org/books/secure-coding/moreinfo.html

Please address any defect reports, comments and suggestions concerning
the Secure Integer Library or CERT Secure Coding Initiative to me.
Thanks to Henry and to Juan Alvarado who coded 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/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

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

[Robert C. Seacord]

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.

In completely unrelated news, a Korean translation of "Secure Coding in
C and C++" (http://www.cert.org/books/secure-coding/) is now available,
although I don't know how you would buy it except maybe by contacting
Pearson Education Asia at http://www.pearsoned-asia.com/

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] managed string library

[Robert C. Seacord]

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

[Robert C. Seacord]

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

[Robert C. Seacord]

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

[Robert C. Seacord]

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
of

[SC-L] Re: Glossary of Terms

[robert]

An existing glossary containing common web application security terminology can 
be found at
http://www.webappsec.org/projects/glossary/. Also available is the Threat 
Classifications document
located at http://www.webappsec.org/projects/threat/ which serves well as a 
taxonomy of attacks .


Regards,

- Robert Auger
[EMAIL PROTECTED]

-
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/

[SC-L] Re: The biggest thing affecting software security? People, apparently.

[Robert Hajime Lanning]

On 6/30/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Your final statement still focus's only on technology i.e. educate 
> programmers.
> Yes I agree they can play a significant part in security applications
> but in my experience the common theme of making everything transparent
> for the users is utter nonesene.
>
> Ordinary users should be educated in security principles to assist in
> understanding the value of data and how their actions could implicate an
> exposure. Especially since we still need to setup users as power users
> or admins in order to operate many third party apps.

Ahh... But you see, with proper security education of programmers, you
wouldn't need to give end users "Power User" or "Administrator" access.
You would teach the programmers how to use the available security framework.

"The person is smart, people are dumb, stupid and panicky." - MIB

You train the ones that build the world, that the end user "lives" in,  about
staying within a secure framework.

-- 
END OF LINE
   -MCP

[SC-L] WASC-Articles: 'The Insecure Indexing Vulnerability - Attacks Against Local Search Engines' By Amit Klein

[robert]

The Web Application Security Consortium is proud to present 'The Insecure 
Indexing 
Vulnerability - Attacks Against Local Search Engines' written by Amit Klein. In 
this article Amit discusses the risks associated with using a local search 
engine
that indexes its content locally.

This document can be found at http://www.webappsec.org/articles/ .

Regards,

- Robert Auger

articles_at_webappsec.org
http://www.webappsec.org


Are you interested in writing a 'Guest Article' for the WASC? Additional 
information
on article guidelines may be found at http://www.webappsec.org/articles/. 
Inquires
can be sent to articles_at_webappsec.org

"Contributed articles may include industry best practices, technical 
information about
current issues, innovative defense techniques, etc. NO VENDOR PITCHES OR 
MARKETING
GIMMICKS PLEASE. We are only soliciting concrete information from the experts 
on the
front lines of the web application security field."
http://www.webappsec.org";>http://www.webappsec.org

 

[SC-L] WASC-Articles: "The 80/20 Rule for Web Application Security"

[robert]

The Web Application Security Consortium is proud to present our first 'Guest 
Article' 
written by Jeremiah Grossman, CTO of WhiteHat Security. The article is entitled 
"The 80/20 Rule for Web Application Security: Increase your security without 
touching the source code" . In this article Jeremiah discusses ways to make 
your website more difficult to exploit with little effort. This document can 
be found at http://www.webappsec.org/articles/013105.html .


Regards,

- Robert Auger

[EMAIL PROTECTED]
http://www.webappsec.org




Are you interested in writing a 'Guest Article' for the WASC? Additional 
information 
on article guidelines may be found at http://www.webappsec.org/articles/. 
Inquires 
can be sent to [EMAIL PROTECTED]

"Contributed articles may include industry best practices, technical 
information about 
current issues, innovative defense techniques, etc. NO VENDOR PITCHES OR 
MARKETING 
GIMMICKS PLEASE. We are only soliciting concrete information from the experts 
on the 
front lines of the web application security field."
http://www.webappsec.org";>http://www.webappsec.org

[SC-L] Web Application Security Consortium 'Guest Articles' Call for Papers

[robert]

Web Application Security Consortium
Guest Articles Call for Papers

The Web Application Security Consortium (WASC) is seeking contributed 
'Guest Articles' by industry professionals on the latest in trends, techniques, 
defenses, best practices and lessons learned relevant to the field of web 
application security.

The importance of web application security has greatly increased in 
recent years due to the exponential growth in threats plaguing the application 
layer of the network. To properly protect systems from application-level 
attacks, the understanding of today's issues has never been more critical. 
It's imperative the industry work together by sharing first-hand experiences 
to combat the growing number of issues. Your contributed articles will assist 
in the advancement of the field of web application security and the education 
of the issues we all face.

Contributed articles may include industry best practices, technical 
information about current issues, innovative defense techniques, etc. 
NO VENDOR PITCHES OR MARKETING GIMMICKS PLEASE. We are only soliciting 
concrete information from the experts on the front lines of the web application 
security field.

Additional information on article guidelines may be found at 
http://www.webappsec.org/articles.html. Inquires can be sent to 
[EMAIL PROTECTED]

We look forward to your submissions.

Project Leader: Robert Auger