CERT C Secure Coding Standard - last call for reviewers

[Robert Seacord]

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

 

[Walter Banks]

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

 

[vippstar]

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:Not really. Once i overflows, UB happends and there is nothing
guaranteed.

referenced by p 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';
}
}

 

[jacob navia]

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/c...ger+values+representing+the+size+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.

 

[Douglas A. Gwyn]

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.

 

[CBFalconer]

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)

 

[CBFalconer]

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.

 

[Richard Heathfield]

CBFalconer said:

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?

 

[jacob navia]

CBFalconer said:


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.

 

[Richard Heathfield]

jacob navia said:

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.

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.

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>

 

[Ed Prochak]

Chuck,

Consider me told. I have seen your message I have read your links
save the off topic posts that everyone else has to endure. If
you must tell me do so privately. I will arrange for my filters to
ignore the messages and you will get the satisfaction of pointing
out a wrong and the rest of the newgroup will not endure endless
off topic threads whose subject line doesn't fit the message
of top vs bottom vs 4 line signature (yours is 9 btw).

Regards,

w..

Walter Banks wrote:

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)

But the rest of us will still have to deal with your top posting.
Please stop. It is annoying.

Note: I did NOT fix your post, I quoted verbatim. Is it really so hard
for you to not top post?

Ed

 

[jacob navia]

Chuck,

[snip]

Falconer is our resident troll. Please just ignore him.

 

[Walter Banks]

Chuck,

Consider me told. I have seen your message I have read your links
save the off topic posts that everyone else has to endure. If
you must tell me do so privately. I will arrange for my filters to
ignore the messages and you will get the satisfaction of pointing
out a wrong and the rest of the newgroup will not endure endless
off topic threads whose subject line doesn't fit the message
of top vs bottom vs 4 line signature (yours is 9 btw).

Regards,

w..

 

[CBFalconer]

Consider me told. I have seen your message I have read your links
save the off topic posts that everyone else has to endure. If
you must tell me do so privately. I will arrange for my filters to
ignore the messages and you will get the satisfaction of pointing
out a wrong and the rest of the newgroup will not endure endless
off topic threads whose subject line doesn't fit the message
of top vs bottom vs 4 line signature (yours is 9 btw).

My attitude has been that you are flipping between areas with
different standards, and forgetting to flip your attitude. I guess
that is wrong. At any rate, top-posting is not really acceptable
in c.l.c., and you would do us a favor by abandoning it.

 

[vippstar]

Another error in the same page is that you clam that code which uses
'rsize_t' is compliant.

This is explained in: https://..

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.

I do not know why and with what intent rsize_t was introduced, but it
adds 0 to computer security.

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.

Would you mind explaining the benifits? Because I see no benifit to
changing all the code I've written so far to use something that adds
nothing to my codes security and is not in standard C. (or any widely
implemented standard, for that matter)

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.

I would not complain about the errors if the link leaded to some
personal web blog or usenet post clarifying the code is pseudo-secure.
However the above link comes from CERT/CC, which according to
wikipedia is a major coordination center and according to them, they
improve security.
I don't know what makes you think that errors in security documents &
papers should be easily excused or ignored.
If you look at securecoding.cert.org there is a link labeled "Top 10
Secure Coding Practices", from which practice n10 is

10. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.

So, according to them, having a *secure* standard is importand, and I
do agree at some degree.
Moreover, this link was posted here, in clc (cross-posted actually;
comp.lang.c comp.std.c) implying the OP seeks technical errors in his
documents.
In fact, mr Seacord (OP) even mentioned so in his post body & title.
Given this, I don't think the OP would be disappointed with my reply.
So, after what I said what had to be said,

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.

would you like to elaborate?
But before you do, consider this: I'm not part of any "clique" (nor I
accuse anybody being a member of a clique) and I'm not trying to troll
you (perhaps you believe that).
It is my honest opinion that this security document is bad at it's
current form.

 

[santosh]

Richard Heathfield wrote:

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.

How can you say this when the recommended language in the GNU Coding
Standards is C?

More or less the same with Microsoft, even if their interest on C
has picked up recently.

Has it? I see no evidence for that.

 

[jacob navia]

How can you say this when the recommended language in the GNU Coding
Standards is C?

Because even if they have since years one of the best
implementations, they do not care enough to fix the
very small problems their implementation has.

I just do not understand that they do 95% of the work and then fail
during *years* to improve anything. Their C99 pges has stayed
the same for years.

Has it? I see no evidence for that.

The recent blog entry by the Microsoft representative, and
their recent TRs and proposals prove this. Thier proposition
for the "secure" functions, even if they did not really
change things is a step forward.

 

[santosh]

Because even if they have since years one of the best
implementations, they do not care enough to fix the
very small problems their implementation has.

I just do not understand that they do 95% of the work and then fail
during *years* to improve anything. Their C99 pges has stayed
the same for years.

That's probably because the gcc developers consider those unimplemented
features either not useful or problematic (like conflicting with
similar gcc specific extensions).

Here is a list of C99 features not fully implemented in mainline gcc:

1. wide character library support in <wchar.h> and <wctype.h>
(originally specified in AMD1).
2.variable-length arrays.
3.complex (and imaginary) support in <complex.h>.
4. extended identifiers.
5. library functions in <inttypes.h>.
6. extended integer types in <stdint.h>.
7. additional math library functions in <math.h>.
8. treatment of error conditions by math library functions
(math_errhandling)
9. IEC 60559 (also known as IEC 559 or IEEE arithmetic) support.
10. additional predefined macro names.
11. standard pragmas.
12. deprecate ungetc at the beginning of a binary file.

Of these 5. 6. don't seem to be present on my version of gcc/glibc, as
far as I can see.

7. 10. 11. and 12. ought to be very easy to implement. I don't know why
they are still unimplemented, though of course 7. and 12. belong to
glibc rather than gcc proper.

1., 8. and 9. should also I think, not be too difficult. I personally
don't care much for 2., 3. and 4.

All told, it *is* surprising that they would come so close to
conformance, but then slow down to a crawl.

The recent blog entry by the Microsoft representative, and
their recent TRs and proposals prove this. Thier proposition
for the "secure" functions, even if they did not really
change things is a step forward.

They need to do more than blog. At least gcc has made a valiant attempt.
Microsoft seem to treat C as a subset of C++ and only the superset
worthy of consideration. That of course leaves C99 in a bad way.

The hot thing these days is "managed" code and "managed" languages,
something C probably can never be. MS recommend C++ even for drivers.

BTW, have you considered submitting patches for one or more of the
missing C99 features in gcc?

 

[Flash Gordon]

jacob navia wrote, On 21/03/08 19:59:

Because even if they have since years one of the best
implementations, they do not care enough to fix the
very small problems their implementation has.

I just do not understand that they do 95% of the work and then fail
during *years* to improve anything. Their C99 pges has stayed
the same for years.

No it hasn't. At the very least one change between gcc 4.2 and gcc 4.3
is that inline functions are no longer broken and gcc 4.3 was release
March 5th this year. Of course, this is still *very* slow movement, but
it is not the complete failure to improve anything you claim.

You say you care yet you have not finished implementing C99 in your
compiler yet. If you are going to claim that not completing C99 is a
sign of lack of care then you had better finish your implementation of
C99 rather than concentrating on things which are not part of C.

The recent blog entry by the Microsoft representative, and
their recent TRs and proposals prove this. Thier proposition
for the "secure" functions, even if they did not really
change things is a step forward.

So MS are still saying they will not implement C99 because there is not
demand unlike GNU who have at least implemented most of it yet MS are
the ones interested in C?

Also gcc have added one of the other extensions for one target which is
of interest to some people, namely fixed point data types described in
n1169.pdf as well as other extensions, so by your suggestion of
extending the language being a sign of interest GNU is still interested.

 

[Keith Thompson]

Because even if they have since years one of the best
implementations, they do not care enough to fix the
very small problems their implementation has.

I just do not understand that they do 95% of the work and then fail
during *years* to improve anything. Their C99 pges has stayed
the same for years.

[...]

*You* complain about this?

When is your own lcc-win going to be fully C99 compliant? So far, you
seem to be spending most of your time inventing and implementing
extensions rather than finishing work on the implementation of the
core language. (That's not to minimize your apparently considerable
efforts in implementing as much of C99 as you have.)