CERT C Programming Language Secure Coding Standard

Discussion in 'C Programming' started by Robert Seacord, Aug 31, 2006.

  1. The CERT/CC has just deployed a new web site dedicated to developing
    secure coding standards for the C programming language, C++, and
    eventually other programming language.

    We have already developed significant content for the C programming
    language that is available at:

    https://www.securecoding.cert.org/

    by clicking on the "CERT C Programming Language Secure Coding Standard"
    link.

    We are depending on the active involvement of the C programming language
    community (you) and ISO/IEC JTC1/SC22/WG14 to make this effort a
    success. I invite you to participate in this effort by reviewing
    content on the web site and providing comments, or by contributing new
    rules and recommendations for secure c coding. These can be sent to me
    directly or to secure-coding at cert dot com.

    I am attaching a press-release like article we wrote below to announce
    the effort. There is also a rationale section on the web site that
    provides more details as to what we are doing and why.

    Thanks,
    rCs

    -------------------

    The Carnegie Mellon Software Engineering Institute (SEI) CERT® Program
    has deployed a secure coding Web site at www.securecoding.cert.org to
    cooperate with the software development community in codifying a
    practical and effective set of secure coding practices for popular
    programming languages. These coding practices can then be used by
    software developers to eliminate vulnerabilities before software is
    operationally deployed.

    The purpose of this project is that the practices can be used by
    developers for professional development and as the basis for
    organizational coding standards supporting the quality of their products.

    Jeffrey Carpenter, manager of the CERT Coordination Center, says that
    the project is part of a larger secure coding initiative within the
    CERT/CC to eliminate dangerous coding practices that can result in
    exploitable software vulnerabilities. According to Carpenter, "CERT is
    in a unique position to coordinate development of a set of secure coding
    practices because of its long history in analyzing and responding to
    software vulnerabilities."

    CERT's initial efforts are focused on the development of secure coding
    practices for the C and C++ programming languages. CERT senior
    vulnerability analyst Robert Seacord is leading the secure coding
    initiative. Seacord is a leading authority on secure coding, author of
    the book Secure Coding in C and C++ [Seacord 05], and technical expert
    for the ISO/IEC JTC1/SC22/WG14 international standardization working
    group for the programming language C.

    "C and C++ were selected because a large percentage of critical
    infrastructures are developed and maintained using these programming
    languages," Seacord says. "C and C++ are popular and viable languages
    although they have characteristics that make them prone to security flaws."

    "Today's dependency on networked software systems has been matched by an
    increase in the number of attacks against governments, corporations,
    educational institutions, and individuals. These attacks result in the
    loss and compromise of sensitive data, system damage, lost productivity,
    and financial loss," says Seacord. To address this growing threat, the
    introduction of software vulnerabilities during development and ongoing
    maintenance must be significantly reduced, if not eliminated.

    CERT recognizes that there are a number of available resources, both
    online and in print, containing coding guidelines, best practices,
    suggestions, and tips. The Motor Industry Software Reliability
    Association (MISRA) developed guidelines for the use of the C language
    in critical systems [MISRA 04], and more recently the U.S. Department of
    Homeland Security launched its Build Security In web site
    (https://buildsecurityin.us-cert.gov) to promote the codification of
    practices and rules. These sources, however, do not provide a
    prescriptive set of secure coding practices that can be uniformly
    applied in the development of a software system.

    "Without secure coding practices, software vulnerability reports are
    likely to continue on an upward trend," Seacord says. "At CERT/CC, we
    have had nearly 4,000 vulnerabilities reported in the first half of
    2006. To stop the threats, we need to develop secure software from the
    outset."

    The secure coding practices proposed by CERT are based on standard
    language versions as defined by official or de facto standards
    organizations such as ISO/IEC. CERT is not an internationally recognized
    standards body, but plans to work with organizations such as ISO/IEC to
    advance the state of the practice in secure coding. The ISO/IEC
    JTC1/SC22 WG14 international standardization working group for the
    programming language C, for example, has offered to provide direction 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 . Robert Seacord can be reached at
    .


    *******************************
    [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.
    --
    comp.lang.c.moderated - moderation address: -- you must
    have an appropriate newsgroups line in your header for your mail to be seen,
    or the newsgroup name in square brackets in the subject line. Sorry.
    Robert Seacord, Aug 31, 2006
    #1
    1. Advertising

  2. Robert Seacord

    Guest

    Robert Seacord wrote:
    > The CERT/CC has just deployed a new web site dedicated to developing
    > secure coding standards for the C programming language, C++, and
    > eventually other programming language.
    >
    > We have already developed significant content for the C programming
    > language that is available at:
    >
    > https://www.securecoding.cert.org/
    >
    > by clicking on the "CERT C Programming Language Secure Coding Standard"
    > link.


    Comments:

    1. A reasonable set of suggestions.

    2. Many of the rules/recommendations are coding practices
    rather than standards. To be a standard the question of
    whether the standard is met must be objective and unambiguous.
    "Strive for clarity", for example, may be good advice but
    it cannot be offered as a "standard".

    3. The explanation in ARR31-C is wrong. In function
    prototypes or definitions, using

    void func(char *a)

    or

    void func(char a[])

    are exactly equivalent whether in the same file or in
    different files. It's declarations outside of function
    parameter lists where the two forms of declaration
    result in different types.
    , Sep 3, 2006
    #2
    1. Advertising

  3. Robert Seacord

    rCs Guest

    comments below.

    > 1. A reasonable set of suggestions.


    thanks. 8^)

    > 2. Many of the rules/recommendations are coding practices
    > rather than standards. To be a standard the question of
    > whether the standard is met must be objective and unambiguous.
    > "Strive for clarity", for example, may be good advice but
    > it cannot be offered as a "standard".


    this is supposed to be a "coding standard" which include a set of rules
    and recommendations for developers to follow. the rules are meant to
    be verifiable, which of course requires they be unambigous. we also
    have recommendations which should also be clear, but not necessarily
    verifiable. "strive for anything" would clearly be a recommendation.
    i couldn't find "Strive for clarity", but there is MSC01-A. Strive for
    Logical Completeness which is a recommendation and, I think, pretty
    clear in its meaning (once you read the description).

    > 3. The explanation in ARR31-C is wrong. In function
    > prototypes or definitions, using
    > void func(char *a)
    > or
    > void func(char a[])
    > are exactly equivalent whether in the same file or in
    > different files. It's declarations outside of function
    > parameter lists where the two forms of declaration
    > result in different types.


    hmm, i read this in "Safer C: Developing Software for High-integrity
    and Safety-critical Systems" by Les Hatton and I'm 99.5% sure I
    verified this in my own tests.

    there is a separate suggestion that this rule needs to be broadened,
    which i plan to evaluate further.

    anyway, thanks for having a look and providing some feedback.

    rCs
    rCs, Sep 3, 2006
    #3
  4. Robert Seacord

    Guest

    rCs wrote:
    > comments below.
    >
    > > 1. A reasonable set of suggestions.

    >
    > thanks. 8^)


    You're welcome!

    > > 2. Many of the rules/recommendations are coding practices
    > > rather than standards. To be a standard the question of
    > > whether the standard is met must be objective and unambiguous.
    > > "Strive for clarity", for example, may be good advice but
    > > it cannot be offered as a "standard".

    >
    > this is supposed to be a "coding standard" which include a set of rules
    > and recommendations for developers to follow. the rules are meant to
    > be verifiable, which of course requires they be unambigous. we also
    > have recommendations which should also be clear, but not necessarily
    > verifiable.


    Yes, I thought that might be how you were dividing it.
    I couldn't always tell. However, since there are both,
    you might consider "Secure Coding Practices and Standards".

    > "strive for anything" would clearly be a recommendation.
    > i couldn't find "Strive for clarity", but there is MSC01-A. Strive for
    > Logical Completeness which is a recommendation and, I think, pretty
    > clear in its meaning (once you read the description).


    Yes, I think I combined the recommendations for clear
    comments and Strive for Logical Completeness to get
    Strive for Clarity. Anyway you got my drift.

    But since you mention it let's look at the Logical Completeness
    recommendation. Consider

    enum WidgetEnum { WE_X, WE_Y, WE_Z } widget_type;
    ...

    switch (widget_type) {
    case WE_X: ...
    case WE_Y: ...
    case WE_Z: ...
    }

    Does the Logical Completeness recommendation mean to
    complain about this switch() statement or not (because
    there is no default: case)? As written, the switch is
    complete, but if another enum value were added it wouldn't
    be. However, depending on the tools being used, it can
    be better to leave off the default: so that the compiler
    can remind us that we need to add a case.

    It's details like these that make writing coding standards
    hard.

    Another example - the recommendation to use a high warning
    level. I agree, but what is meant by "high" is different
    for different people. It would help the discussion and
    also help strengthen the standard if the different sorts
    of conditions that should be warned on if possible were
    included, as (examples only!):

    variable possibly used without being initialized
    variable never used
    signed/unsigned comparison
    character literal assigned to non-const pointer
    ...

    Maybe another way of saying this is that you're on the
    right track but there needs to be more specifics.

    > > 3. The explanation in ARR31-C is wrong. In function
    > > prototypes or definitions, using
    > > void func(char *a)
    > > or
    > > void func(char a[])
    > > are exactly equivalent whether in the same file or in
    > > different files. It's declarations outside of function
    > > parameter lists where the two forms of declaration
    > > result in different types.

    >
    > hmm, i read this in "Safer C: Developing Software for High-integrity
    > and Safety-critical Systems" by Les Hatton and I'm 99.5% sure I
    > verified this in my own tests.
    >
    > there is a separate suggestion that this rule needs to be broadened,
    > which i plan to evaluate further.


    There's no question that the rule applies to top level
    declarations. And the rules C has for type compatibility
    aren't always obvious, so it's good to point out common
    cases that can lead to bad behavior.

    > anyway, thanks for having a look and providing some feedback.


    No problem. I'm surprised more of the regulars didn't
    say anything, this effort looks like it's going in
    the right direction.

    By the way, you might want to add a memory management
    rule:

    Don't cast the return value of malloc (when used in
    simple assignment).

    The reasoning being, code like

    int *p;

    p = (int *) malloc( sizeof *p );

    can mask errors if there is no earlier declaration of
    malloc. That's also true of functions generally, but
    the problem seems especially common with malloc.

    That reminds me of something else, which is function
    prototypes. I suggest adding a rule

    All function calls and function defintions should
    be preceded by a function prototype.

    And, if possible, exactly one, and checked by the
    compiler. (Of course I mean prototype to include
    declaring the types of the function's parameters.)
    , Sep 3, 2006
    #4
  5. Robert Seacord

    Guest

    rCs wrote:
    ....
    > > 2. Many of the rules/recommendations are coding practices
    > > rather than standards. To be a standard the question of
    > > whether the standard is met must be objective and unambiguous.
    > > "Strive for clarity", for example, may be good advice but
    > > it cannot be offered as a "standard".

    >
    > this is supposed to be a "coding standard" which include a set of rules
    > and recommendations for developers to follow. the rules are meant to
    > be verifiable, which of course requires they be unambigous. we also
    > have recommendations which should also be clear, but not necessarily
    > verifiable.


    That's precisely the point. If it's not verifiable, it doesn't belong
    in something called a "coding standard". You could call it "coding
    advice", but it isn't a coding standard. With something that vague, it
    doesn't even qualify as a guideline - a guiide line is something that
    identifies the correct path sufficiently precisely to ensure your
    arrival at your destination; programming advice that vague doesn't
    qualify for the metaphor.

    > > 3. The explanation in ARR31-C is wrong. In function
    > > prototypes or definitions, using
    > > void func(char *a)
    > > or
    > > void func(char a[])
    > > are exactly equivalent whether in the same file or in
    > > different files. It's declarations outside of function
    > > parameter lists where the two forms of declaration
    > > result in different types.

    >
    > hmm, i read this in "Safer C: Developing Software for High-integrity
    > and Safety-critical Systems" by Les Hatton and I'm 99.5% sure I
    > verified this in my own tests.


    What form did your test take? Did you try building the examples of
    non-compliant and compliant code that are provided with ARR31-C? Those
    examples demonstrate, correctly, that if something is defined as a
    global pointer in one translation unit(TU), and incompletely declared
    as a global array of unspecified size in another TU, the two
    declarations are indeed incompatible in a way that can cause serious
    trouble.

    However, the advice that goes with the example is about the declaration
    of function arguments, not the declaration of global variables. That
    advice is wrong, and has nothing to do with the example given. The two
    declarations of func() are exactly equivalent, and it doesn't matter
    whether they're in the same TU or different TUs.
    , Sep 3, 2006
    #5
  6. Robert Seacord

    rCs Guest

    the points you make below are exactly the points i was trying to make
    in ARR31-C. i've tried to make it a little clearer, and may revise
    further tomorrow.

    wrote:

    > What form did your test take? Did you try building the examples of
    > non-compliant and compliant code that are provided with ARR31-C? Those
    > examples demonstrate, correctly, that if something is defined as a
    > global pointer in one translation unit(TU), and incompletely declared
    > as a global array of unspecified size in another TU, the two
    > declarations are indeed incompatible in a way that can cause serious
    > trouble.
    >
    > However, the advice that goes with the example is about the declaration
    > of function arguments, not the declaration of global variables. That
    > advice is wrong, and has nothing to do with the example given. The two
    > declarations of func() are exactly equivalent, and it doesn't matter
    > whether they're in the same TU or different TUs.


    rCs
    rCs, Sep 5, 2006
    #6
  7. Robert Seacord

    CBFalconer Guest

    Robert Seacord wrote:
    >
    > The CERT/CC has just deployed a new web site dedicated to developing
    > secure coding standards for the C programming language, C++, and
    > eventually other programming language.
    >
    > We have already developed significant content for the C programming
    > language that is available at:
    >
    > https://www.securecoding.cert.org/
    >
    > by clicking on the "CERT C Programming Language Secure Coding Standard"
    > link.

    ..... snip ...

    I took a more or less random look at that site, and found this:

    STR30-C. Do not attempt to modify string literals
    STR31-C. Do not copy data from an unbounded source to a
    fixed-length array
    STR32-C. Allocated adequate space when copying bounded strings
    STR33-C. Guarantee that all strings are null-terminated
    STR34-C. Do not truncate strings while copying

    which seems pretty banal to me.

    First, it is not legal to modify string literals, such attempts
    result in undefined behaviour. With gcc at least, you can arrange
    for them to be declared as const, and thus get compiler warnings.

    Second and third, the only kind of array available in C is a fixed
    length array. The programmer needs to ensure that the length is
    adequate. The same applies to copying strings. You may be
    thinking of the sort of thing that my ggets handles - see:

    <http://cbfalconer.home.att.net/download/>

    or that strlcpy/strlcat handles. See same place.

    Fourth, without a zero (not null) termination, a char array is not
    even a string.

    Fifth, why not truncate strings? The usefulness depends on the
    circumstances. Truncation is certainly always more attractive than
    overflowing storage.

    My conclusion - the advice is worthless to all but the rankest
    beginners. A reading of the C-faq is more productive.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE maineline address!
    --
    comp.lang.c.moderated - moderation address: -- you must
    have an appropriate newsgroups line in your header for your mail to be seen,
    or the newsgroup name in square brackets in the subject line. Sorry.
    CBFalconer, Sep 18, 2006
    #7
  8. Robert Seacord

    Bill Pursell Guest

    Robert Seacord wrote:
    > The CERT/CC has just deployed a new web site dedicated to developing
    > secure coding standards for the C programming language, C++, and
    > eventually other programming language.
    >


    I downloaded some of the code snippets, and the first one
    I tested compiled with the following warnings:

    [Chapter_3]$ gcc -Wall -pedantic Figure3-12-unix.c
    Figure3-12-unix.c: In function `main':
    Figure3-12-unix.c:27: warning: implicit declaration of function
    `atexit'
    Figure3-12-unix.c:29: warning: control reaches end of non-void function

    I am not sure it's worth looking too closely if the very first sample
    behaves like that.

    --
    Bill Pursell
    --
    comp.lang.c.moderated - moderation address: -- you must
    have an appropriate newsgroups line in your header for your mail to be seen,
    or the newsgroup name in square brackets in the subject line. Sorry.
    Bill Pursell, Sep 18, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Seacord

    CERT C Programming Language Secure Coding Standard

    Robert Seacord, Jul 31, 2007, in forum: C Programming
    Replies:
    16
    Views:
    536
    Eric Sosman
    Aug 3, 2007
  2. rCs
    Replies:
    0
    Views:
    305
  3. Robert Seacord
    Replies:
    118
    Views:
    2,647
    Douglas A. Gwyn
    Apr 22, 2008
  4. rCs
    Replies:
    12
    Views:
    1,277
    Abu Yahya
    Jun 8, 2011
  5. David Chan via .NET 247
    Replies:
    1
    Views:
    330
    Dominick Baier [DevelopMentor]
    Jun 2, 2005
Loading...

Share This Page