Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > CERT C Secure Coding Standard - last call for reviewers

Reply
Thread Tools

CERT C Secure Coding Standard - last call for reviewers

 
 
Robert Seacord
Guest
Posts: n/a
 
      03-20-2008

We would like to invite the C community to review and comment on the
current version of the CERT C Secure Coding Standard available online at
www.securecoding.cert.org <http://www.securecoding.cert.org> before
Version 1.0 is published. To comment, you can create an account on the
Secure Coding wiki and post your comments there.

Our intent is to complete major development of Version 1.0 by April 18,
2008, with the published version of the standard being available in
September. Once Version 1.0 of the standard goes to the publisher, we
will begin development of Version 2.0. That is, we will continue to
maintain the wiki to further advance the "working version" of the CERT C
Secure Coding Standard. The published 1.0 version will become the
official version, until replaced by a future version. It is unlikely a
subsequent version will be released any time in the next 2-3 years, so
we would like to ensure that Version 1.0 will be a high quality product
that will promote and encourage secure coding practices.

Thanks for any help and assistance you have already provided and for any
additional contribution you may make. There are currently 184
individuals who have contributed to the development of this standard,
without whom this effort could not have succeeded.

Thanks,
rCs

--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC
Work: 412-268-7608
FAX: 412-268-6989
 
Reply With Quote
 
 
 
 
Walter Banks
Guest
Posts: n/a
 
      03-20-2008
Robert,

It has been a while since I looked at your wiki on secure coding and forgot
how important and clear it was on good coding practice. I would like to
link the wiki from our website as a service to our customers writing code
for embedded systems applications.

Let me know when it is published and I will be happy to have an item
posted on that as well.

Nice piece of work

Walter Banks
Byte Craft Limited


Robert Seacord wrote:

> We would like to invite the C community to review and comment on the
> current version of the CERT C Secure Coding Standard available online at
> www.securecoding.cert.org <http://www.securecoding.cert.org> before
> Version 1.0 is published. To comment, you can create an account on the
> Secure Coding wiki and post your comments there.
>
> Our intent is to complete major development of Version 1.0 by April 18,
> 2008, with the published version of the standard being available in
> September. Once Version 1.0 of the standard goes to the publisher, we
> will begin development of Version 2.0. That is, we will continue to
> maintain the wiki to further advance the "working version" of the CERT C
> Secure Coding Standard. The published 1.0 version will become the
> official version, until replaced by a future version. It is unlikely a
> subsequent version will be released any time in the next 2-3 years, so
> we would like to ensure that Version 1.0 will be a high quality product
> that will promote and encourage secure coding practices.
>
> Thanks for any help and assistance you have already provided and for any
> additional contribution you may make. There are currently 184
> individuals who have contributed to the development of this standard,
> without whom this effort could not have succeeded.
>
> Thanks,
> rCs
>
> --
> Robert C. Seacord
> Senior Vulnerability Analyst
> CERT/CC
> Work: 412-268-7608
> FAX: 412-268-6989


 
Reply With Quote
 
 
 
 
vippstar@gmail.com
Guest
Posts: n/a
 
      03-20-2008
On Mar 20, 4:02 pm, Robert Seacord <(E-Mail Removed)> wrote:
> We would like to invite the C community to review and comment on the
> current version of the CERT C Secure Coding Standard available online atwww.securecoding.cert.org<http://www.securecoding.cert.org> before
> Version 1.0 is published. To comment, you can create an account on the
> Secure Coding wiki and post your comments there.

I read a few pages, quoting from INT01-A:
>> The size_t type is typically represented by the same number of bits as int,
>> that is, sizeof(size_t) == sizeof(int)). In this case, n >>might be greater
>> than INT_MAX. The loop, however, will executes n times because the
>> comparison i < n is an unsigned comparison. Once i >> > INT_MAX, i takes on
>> negative values starting with (INT_MIN). Consequently, the memory locations

Not really. Once i overflows, UB happends and there is nothing
guaranteed.
>> referenced by p[i] precede the >> memory referenced by p and a
>> write-outside-array bounds occurs.

I assume this collection of documents has more errors such as the one
I mentioned.
(The assumption is done because I only read 2 or perhaps 3 pages from
your link and wasted 10 minutes)
Another error in the same page is that you clam that code which uses
'rsize_t' is compliant.

Secure programming is beyond C's UB. Perfectly conforming programs can
still be insecure, your pages seem to have neither. (conforming or
secure programs).

Update: okay, in that *same* page (INT01-A) I found this code which
claims to be secure & conforming

>> #define BUFF_SIZE 10
>> int main(int argc, char *argv[]){
>> rsize_t size;
>> char buf[BUFF_SIZE];
>> size = atoi(argv[1]); /* vipp: atoi in secure code? */
>> /* vipp: where are your checks for argc? */
>> if (size < BUFF_SIZE){
>> strncpy(buf, argv[2], size); /* vipp: ka-boom */
>> buf[size] = '\0';
>> }
>> }

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-20-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Another error in the same page is that you clam that code which uses
> 'rsize_t' is compliant.
>


This is explained in:
https://www.securecoding.cert.org/co...e+of+an+object

The type size_t generally covers the entire address space. [TR 24731-1]
introduces a new type rsize_t, defined to be size_t but explicitly used
to hold the size of a single object. In code that documents this
purpose by using the type rsize_t, the size of an object can be checked
to verify that it is no larger than RSIZE_MAX, the maximum size of a
normal single object, which provides additional input validation for
library functions. See [STR00-A. Use TR 24731 for remediation of
existing string manipulation code] for additional discussion of TR 24731-1.

Any variable that is used to represent the size of an object including
integer values used as sizes, indices, loop counters, and lengths should
be declared as rsize_t if available.

> Secure programming is beyond C's UB. Perfectly conforming programs can
> still be insecure, your pages seem to have neither. (conforming or
> secure programs).
>
> Update: okay, in that *same* page (INT01-A) I found this code which
> claims to be secure & conforming
>
>>> #define BUFF_SIZE 10
>>> int main(int argc, char *argv[]){
>>> rsize_t size;
>>> char buf[BUFF_SIZE];
>>> size = atoi(argv[1]); /* vipp: atoi in secure code? */
>>> /* vipp: where are your checks for argc? */
>>> if (size < BUFF_SIZE){
>>> strncpy(buf, argv[2], size); /* vipp: ka-boom */
>>> buf[size] = '\0';
>>> }
>>> }


This is bogus. The code is trying to explain one specific problem, i.e.
that signed int comparisons with some constant assume that the integer
is greater than zero implicitely. To avoid this, rsize_t is recommended.

Conclusion:

I wasted 10 minutes to read your message. You have no comprehension
about what the code examples are intended to show, and you start
complaining about things that do not concern the example directly.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Douglas A. Gwyn
Guest
Posts: n/a
 
      03-21-2008
jacob navia wrote:
> This is bogus. The code is trying to explain one specific problem, i.e.
> that signed int comparisons with some constant assume that the integer
> is greater than zero implicitely. To avoid this, rsize_t is recommended.


I think the point was valid: If examples are given, they ought
to follow *all* the "good practice guidelines". The exhibited
code had *several* security, portability, and reliability issues.

Concentrating on some presumed benefit of rsize_t rather than
genuinely serious safety issues is bad strategy and bad tactics.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-21-2008
Walter Banks wrote:
>
> It has been a while since I looked at your wiki on secure coding
> and forgot how important and clear it was on good coding practice.
> I would like to link the wiki from our website as a service to our
> customers writing code for embedded systems applications.
>
> Let me know when it is published and I will be happy to have an
> item posted on that as well.


Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-21-2008
Robert Seacord wrote:
>
> We would like to invite the C community to review and comment on the
> current version of the CERT C Secure Coding Standard available online
> at www.securecoding.cert.org <http://www.securecoding.cert.org>
> before Version 1.0 is published. To comment, you can create an
> account on the Secure Coding wiki and post your comments there.


I could find no way to download a draft.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-21-2008
CBFalconer said:

> Walter Banks wrote:
>>
>> It has been a while since I looked at your wiki on secure coding
>> and forgot how important and clear it was on good coding practice.
>> I would like to link the wiki from our website as a service to our
>> customers writing code for embedded systems applications.
>>
>> Let me know when it is published and I will be happy to have an
>> item posted on that as well.

>
> Please do not top-post.


Those who have nothing to say should say nothing, and those who breach
netiquette guidelines should stop doing so before preaching netiquette to
others.

Now - secure coding.

I have a few questions about the document. Firstly, why is it based on C99?
Is it because it was written at a time when C99 take-up was anticipated
more optimistically?

The trouble is that this dependence makes the document itself less useful
than it might be. By encouraging the use of inline functions over macros,
for example, you're actually encouraging people to make their code
uncompilable under C90. If C99 were as widely implemented as C90, that
wouldn't be a problem. But it isn't.

I said I had a few questions, but during the course of asking the last one
I had two browser crashes. Does the OP have a single-page
(very-long-page!) version available for download?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-21-2008
Richard Heathfield wrote:
> CBFalconer said:
>
>> Walter Banks wrote:
>>> It has been a while since I looked at your wiki on secure coding
>>> and forgot how important and clear it was on good coding practice.
>>> I would like to link the wiki from our website as a service to our
>>> customers writing code for embedded systems applications.
>>>
>>> Let me know when it is published and I will be happy to have an
>>> item posted on that as well.

>> Please do not top-post.

>
> Those who have nothing to say should say nothing, and those who breach
> netiquette guidelines should stop doing so before preaching netiquette to
> others.
>
> Now - secure coding.
>
> I have a few questions about the document. Firstly, why is it based on C99?
> Is it because it was written at a time when C99 take-up was anticipated
> more optimistically?
>


C99 is standard C, and they are correct using it. If you do not like
standard C or feel that you have to wage your personal little war
against the standard go elsewhere.

> The trouble is that this dependence makes the document itself less useful
> than it might be.


Do not use it then.

> By encouraging the use of inline functions over macros,
> for example, you're actually encouraging people to make their code
> uncompilable under C90.


C90 is no longer standard C since 1999.

If C99 were as widely implemented as C90, that
> wouldn't be a problem. But it isn't.
>


There are several implementations. Gcc's implementation is almost
ready. They did not finish it because C has disappeared from
their objectives. GNU doesn't care about the language anymore.
More or less the same with Microsoft, even if their interest on C
has picked up recently.


> I said I had a few questions, but during the course of asking the last one
> I had two browser crashes. Does the OP have a single-page
> (very-long-page!) version available for download?
>



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-21-2008
jacob navia said:

> Richard Heathfield wrote:
>> CBFalconer said:
>>
>>> Walter Banks wrote:
>>>> It has been a while since I looked at your wiki on secure coding
>>>> and forgot how important and clear it was on good coding practice.
>>>> I would like to link the wiki from our website as a service to our
>>>> customers writing code for embedded systems applications.
>>>>
>>>> Let me know when it is published and I will be happy to have an
>>>> item posted on that as well.
>>> Please do not top-post.

>>
>> Those who have nothing to say should say nothing, and those who breach
>> netiquette guidelines should stop doing so before preaching netiquette
>> to others.
>>
>> Now - secure coding.
>>
>> I have a few questions about the document. Firstly, why is it based on
>> C99? Is it because it was written at a time when C99 take-up was
>> anticipated more optimistically?
>>

>
> C99 is standard C, and they are correct using it.


I didn't say they were incorrect to use it. I asked *why* they used it.

> If you do not like standard C or feel that you have to wage your
> personal little war against the standard go elsewhere.


I think my question was reasonable. If you don't like what I write, well,
nobody is forcing you to read it.

>> The trouble is that this dependence makes the document itself less
>> useful than it might be.

>
> Do not use it then.


Is that the recommendation of the OP, too? That people who wish to write
portable code should not use the CERT C thing? I'd like to hear that from
him, rather than you, since it's his document.

>> By encouraging the use of inline functions over macros,
>> for example, you're actually encouraging people to make their code
>> uncompilable under C90.

>
> C90 is no longer standard C since 1999.


By that reasoning, lcc-win32 hasn't been a conforming implementation for
over eight years, and it remains non-conforming today, so please stop
banging on about it in comp.lang.c all the time because - by *your*
argument - it isn't a C compiler.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
CERT C Secure Coding Standard: last call for reviewers rCs C Programming 0 03-17-2008 08:22 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSE 4 11-15-2006 02:40 AM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola Microsoft Certification 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd loyola MCSD 3 11-14-2006 05:18 PM
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd realexxams@yahoo.com Microsoft Certification 0 05-10-2006 02:35 PM



Advertisments