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

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

ction in
the development of the C language secure coding practices and to review
and comment on drafts of the informal CERT standard.

According to WG14 convener John Benito, "The secure coding standard is
going in the correct direction, and I have confidence the final product
will be useful to the community."

CERT is also working with standards groups, such as the ISO/IEC working
group on Guidance for Avoiding Vulnerabilities through Language Use
(OWGV).  While the ISO/IEC group is working on providing
language-independent guidance, the CERT effort is working on developing
and consolidating the language-specific guidance that provides the
foundations for the ambitious goals of OWGV.

Jim Moore, convener of OWGV, states that "CERT's efforts in identifying
and documenting secure coding practices for C and C++ will contribute to
the standardization of these practices and advance the goals of the OWGV."

Community Involvement

The success of the secure coding standards depends largely on the active
involvement of members of the secure software and C and C++ development
communities. Rules and recommendations for each coding practice are
solicited from the communities involved in the development and
application of each programming language, including the formal or de
facto standard bodies responsible for the documented standard.

These rules and recommendations are edited by CERT senior members of the
technical staff for content and style, and placed in Secure Coding
Standards Web site for comment and review. The user community is invited
to discuss and comment on the publicly posted content. Once a consensus
develops that the rule or recommendation is appropriate and correct, the
final rule is incorporated into the coding standard.

Once practices are documented, tools can be developed or modified to
verify compliance. Compliant software systems may then be certified as
compliant by a properly authorized certification body. Seacord also
envisions a training and development program to educate software
professionals regarding the appropriate application of secure coding
practices.

The development of secure coding practices is a necessary step to stem
the ever-increasing threat from software vulnerabilities. CERT's goal is
that the enumeration of secure code practices will allow for a common
set of criteria that can be used to measure and evaluate software
development efforts.

The public can review or comment on the existing content at the secure
coding Web site or submit new ideas for secure coding practices by
e-mailing [EMAIL PROTECTED] Robert Seacord can be reached at
[EMAIL PROTECTED]


***
[1] Seacord, R. Secure Coding in C and C++. Addison-Wesley, 2005. See
http://www.cert.org/books/secure-coding for news and errata.

[2] MISRA C: 2004 Guidelines for the use of the C language in Critical
systems. MIRA Limited. Warsickshire, UK. October 2004. ISBN 0 9524156.




-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Re: [SC-L] secure integer library

[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