security coding guidelines for C/C++

Discussion in 'C Programming' started by Aravind, May 24, 2004.

  1. Aravind

    Aravind Guest

    I am Aravind.Could someone provide me with a list of specific
    guidelines for secure programming in C/C++?.I would like to use those
    guidelines for developing a security application to deal with issues
    like buffer overflows,memory leaks,user input validation etc....
    Aravind
     
    Aravind, May 24, 2004
    #1
    1. Advertising

  2. Aravind

    CBFalconer Guest

    Aravind wrote:
    >
    > I am Aravind.Could someone provide me with a list of specific
    > guidelines for secure programming in C/C++?.I would like to use those
    > guidelines for developing a security application to deal with issues
    > like buffer overflows,memory leaks,user input validation etc....


    No. Nobody here ever heard of the language C/C++. On the other
    hand, the C++ group is down the hall to the right, and we do deal
    with C here.

    --
    A: Because it fouls the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    CBFalconer, May 24, 2004
    #2
    1. Advertising

  3. Aravind

    Malcolm Guest

    "Aravind" <> wrote in message
    >
    > I am Aravind.Could someone provide me with a list of specific
    > guidelines for secure programming in C/C++?.
    > I would like to use those guidelines for developing a security
    > application to deal with issues like buffer overflows,memory
    > leaks,user input validation etc....
    >

    Security is a real problem for C programs, and it is not easy to write tools
    to check for it.
    The worst problem is when user input overflows an "auto" (stack) array, on
    systems where this corrupts the reurn stack. An attacker can use this to
    induce a jump to a location of his choosing, and thus introduce malicious
    code.
    It is also possible to oveflow the stack. For instance the code

    double eval( char *expr)
    {
    ...
    if(*expr == '9')
    temp = eval(expr+1);
    ...
    }

    can be caused to crash by inputting a huge number of open parentheses.

    You simply have to be careful to call malloc() with the right size, not
    overstep the array, check the return value, and free memory after you have
    done with it. The good news is that there is little the user can do to wreck
    things here. (To test, a good technique is to provide a version of malloc()
    that fails periodically).

    For user input, be aware that the user can type anything, and assume he is
    trying to wreck your program and has a copy of the source.
     
    Malcolm, May 24, 2004
    #3
  4. On Mon, 24 May 2004 21:00:08 +0100, Malcolm wrote:

    >
    > "Aravind" <> wrote in message
    >>
    >> I am Aravind.Could someone provide me with a list of specific
    >> guidelines for secure programming in C/C++?.
    >> I would like to use those guidelines for developing a security
    >> application to deal with issues like buffer overflows,memory
    >> leaks,user input validation etc....
    >>

    > Security is a real problem for C programs, and it is not easy to write tools
    > to check for it.
    > The worst problem is when user input overflows an "auto" (stack) array, on
    > systems where this corrupts the reurn stack. An attacker can use this to
    > induce a jump to a location of his choosing, and thus introduce malicious
    > code.


    This is largely obviated by either fgets() or the much better
    fgetc()/realloc() method, or something very similar adapted to your
    specific input environment.

    For a good example of the fgetc()/realloc() method, see the fggets()
    implementation by CBFalconer:

    http://cbfalconer.home.att.net/download/ggets.zip

    > It is also possible to oveflow the stack. For instance the code
    >
    > double eval( char *expr)
    > {
    > ...
    > if(*expr == '9')
    > temp = eval(expr+1);
    > ...
    > }
    >
    > can be caused to crash by inputting a huge number of open parentheses.


    Or, in your case, a large number of nines. ;-)

    This is probably the most serious problem if you fail to plan ahead.
    Scanning the string beforehand to see if all of the parens match and if
    the nesting is too deep could be valuable, or you could give eval a static
    int that says how many layers deep the recursion has gone. If the int gets
    too big, you return badly.

    Of course, how deep is too deep is somewhat up in the air. Do any of the
    standards specify the minimum recursion depth an implementation must
    support?

    >
    > You simply have to be careful to call malloc() with the right size, not
    > overstep the array, check the return value, and free memory after you have
    > done with it. The good news is that there is little the user can do to wreck
    > things here.


    And, of course, always #include <stdlib.h> and never cast its return value.

    > (To test, a good technique is to provide a version of malloc()
    > that fails periodically).


    That, or begin developing big programs for small machines. ;-)

    >
    > For user input, be aware that the user can type anything, and assume he is
    > trying to wreck your program and has a copy of the source.


    Indeed. This is the best possible route to defensive programming, and I
    wish more Microsoft programmers (for example) thought this way.

    --
    yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
    To email me, rot13 and convert spelled-out numbers to numeric form.
    "Makes hackers smile" makes hackers smile.
     
    August Derleth, May 25, 2004
    #4
  5. In article <>,
    August Derleth <> wrote:

    > On Mon, 24 May 2004 21:00:08 +0100, Malcolm wrote:
    > >
    > > For user input, be aware that the user can type anything, and assume he is
    > > trying to wreck your program and has a copy of the source.

    >
    > Indeed. This is the best possible route to defensive programming, and I
    > wish more Microsoft programmers (for example) thought this way.


    I think it is too weak.

    For input, assume the input doesn't come from a user, but from a
    completely unscrupulous attacker who is paid serious money to cause as
    much damage as possible.

    Assume that the attacker has both the source code and the assembler
    code; the source code is useful to find where your program has undefined
    behaviour according to the C Standard, the assembler code tells the
    attacker what your implementation actually does in the case of undefined
    behavior.

    Assume that the attacker's goal is not just to crash your program, but
    to take control of your computer, and any undefined behavior in your
    programmer could give the attacker the means to achieve this. Just
    assume that a successful attacker will force the computer to send _your_
    name, address, date of birth, mother's maiden name, social security,
    passport, driver license and credit card numbers, bank details and so on
    to the attacker, leaving a ghastly amount of child pornography on your
    computer in exchange which will be discovered by your
    employer/wife/girlfriend, leading to job loss/loss of important body
    parts and several years of jailtime. That should keep you motivated, and
    motivation is the most important thing for secure programming.
     
    Christian Bau, May 25, 2004
    #5
  6. The problems of buffer overflows could soon become less relevant anyway,
    with Intel and AMD's new chips at least (Not that I'm suggesting in anyway
    that it shouldnt still be protected against!). And NX does require OS
    support as well.
    http://www.internet-security.ca/int...l-end-buffer-overflows-security-problems.html
    What a god send for Microsoft, easier to include NX support in a service
    pack than to correct all the 50m lines of code i suppose, it will be
    interesting to see which path they take!

    The Fat Man

    "Aravind" <> wrote in message
    news:...
    > I am Aravind.Could someone provide me with a list of specific
    > guidelines for secure programming in C/C++?.I would like to use those
    > guidelines for developing a security application to deal with issues
    > like buffer overflows,memory leaks,user input validation etc....
    > Aravind
     
    Matthew Jakeman, May 25, 2004
    #6
  7. Prescott, was re: security coding guidelines for C/C++

    On Tue, 25 May 2004, Matthew Jakeman wrote:
    >

    [re: discussion of security in C/C++ programs]
    >
    > The problems of buffer overflows could soon become less relevant anyway,
    > with Intel and AMD's new chips at least (Not that I'm suggesting in anyway
    > that it shouldnt still be protected against!). And NX does require OS
    > support as well.
    > http://www.internet-security.ca/int...l-end-buffer-overflows-security-problems.html
    > What a god send for Microsoft, easier to include NX support in a service
    > pack than to correct all the 50m lines of code i suppose, it will be
    > interesting to see which path they take!


    The press release doesn't say much about the technology, but from
    what I can gather, it's basically making the stack segment
    read-and-write-only, no execution privileges. I thought Intel machines
    had segments you couldn't execute from already, like the data segment?
    No?
    And if it is what I think it is, then it doesn't protect against
    an attacker's taking over your machine: it only protects against an
    attacker's being able to take over your machine with code he wrote
    himself and inserted into the stack frame. A static-buffer overflow
    *followed by* a stack-buffer overflow executing a jump into the
    overflowed static buffer would be just as devastating as the old kind;
    and stack-buffer overflows could still make the computer crash or
    execute the wrong code.
    So is the "Magic Lamp to end buffer overflow exploits" tagline just
    normal media hype, or am I really missing something WRT the capabilities
    of the "new" technology?

    (Fup-to: comp.programming. comp.lang.c will thank you.)

    -Arthur
     
    Arthur J. O'Dwyer, May 25, 2004
    #7
  8. Aravind

    Paul Hsieh Guest

    Re: Prescott, was re: security coding guidelines for C/C++

    "Arthur J. O'Dwyer" <> wrote:
    > On Tue, 25 May 2004, Matthew Jakeman wrote:
    > [re: discussion of security in C/C++ programs]
    > >
    > > The problems of buffer overflows could soon become less relevant anyway,
    > > with Intel and AMD's new chips at least (Not that I'm suggesting in anyway
    > > that it shouldnt still be protected against!). And NX does require OS
    > > support as well.
    > > http://www.internet-security.ca/int...l-end-buffer-overflows-security-problems.html
    > > What a god send for Microsoft, easier to include NX support in a service
    > > pack than to correct all the 50m lines of code i suppose, it will be
    > > interesting to see which path they take!

    >
    > The press release doesn't say much about the technology, but from
    > what I can gather, it's basically making the stack segment
    > read-and-write-only, no execution privileges. I thought Intel machines
    > had segments you couldn't execute from already, like the data segment?
    > No?


    No. First of all this is a feature that comes from AMD, and has
    already been implemented in the Athlon-64 CPUs. Its called the
    No-Execute bit, and its a mode that's just been missing in the x86
    architecture before AMD added it to AMD64. The OpenBSD folks have
    added it to their architecture in anticipation of this being enabled
    in x86s.

    > And if it is what I think it is, then it doesn't protect against
    > an attacker's taking over your machine: it only protects against an
    > attacker's being able to take over your machine with code he wrote
    > himself and inserted into the stack frame.


    Right. But this is a very common problem and exploit. For example
    one of the software based X-box mods rely on exactly this flaw in the
    initial dashboard background image loader.

    > [...] A static-buffer overflow
    > *followed by* a stack-buffer overflow executing a jump into the
    > overflowed static buffer would be just as devastating as the old kind;
    > and stack-buffer overflows could still make the computer crash or
    > execute the wrong code.


    Yes, you can still crash the machine. Making it execute code you've
    crafted yourself though -- you'll have to rely on other holes.

    > So is the "Magic Lamp to end buffer overflow exploits" tagline just
    > normal media hype, or am I really missing something WRT the capabilities
    > of the "new" technology?


    It solves one manifestation of the problem. I've thought about this
    problem for a little bit, and I am not sure it will be ended by using
    this mechanism -- just that it needs to be a lot more creative. I.e.,
    to spurr a program to arbitrary action you have to prime it by forcing
    it to jump into *its own* code segment, however with the *parameters*
    on the stack may be arbitrarily modified. (So for example if the code
    itself has a call in it to turn the NX bit on and off, then you can
    call that code with parameters that say turn it off, *then* do the
    same exploit, etc.)

    > (Fup-to: comp.programming. comp.lang.c will thank you.)


    Its not off topic for comp.lang.c. Remember C, and C alone is the
    language that creates this problem.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
     
    Paul Hsieh, May 27, 2004
    #8
  9. Re: Prescott, was re: security coding guidelines for C/C++

    In article <>, (Paul Hsieh) writes:
    > "Arthur J. O'Dwyer" <> wrote:
    >
    > > So is the "Magic Lamp to end buffer overflow exploits" tagline just
    > > normal media hype, or am I really missing something WRT the capabilities
    > > of the "new" technology?

    >
    > It solves one manifestation of the problem. I've thought about this
    > problem for a little bit, and I am not sure it will be ended by using
    > this mechanism -- just that it needs to be a lot more creative.


    I largely agree with what Paul had to say in his post, but I'd like
    to point out that while return-into-program exploits no doubt are
    more difficult than return-into-buffer ones, they're well-understood,
    there's some good technical information on them and practical advice
    on writing them available, and they've been found "in the wild".
    (See eg the Bugtraq archives, or past issues of Phrack, for more
    information.)

    In other words, attackers already know how to exploit return-into-
    program buffer overflow holes, so patching return-into-buffer (with a
    non-exec page bit) really just eliminates some of the low-hanging
    fruit.

    > > (Fup-to: comp.programming. comp.lang.c will thank you.)

    >
    > Its not off topic for comp.lang.c. Remember C, and C alone is the
    > language that creates this problem.


    C programs may be the worst offenders, and language features have
    certainly contributed to that. But it's hardly alone. For one thing,
    there are plenty of poorly-written C++ programs that suffer from the
    same problems.

    --
    Michael Wojcik

    Although he was an outsider, and excluded from their rites, they were
    always particularly charming to him at this time; he and his household
    received small courtesies and presents, just because he was outside.
    -- E M Forster
     
    Michael Wojcik, May 28, 2004
    #9
    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. Francisco Camarero

    VHDL Coding Guidelines

    Francisco Camarero, Jul 8, 2003, in forum: VHDL
    Replies:
    1
    Views:
    2,086
  2. Roger

    Portable Coding Guidelines?

    Roger, Dec 17, 2004, in forum: VHDL
    Replies:
    0
    Views:
    551
    Roger
    Dec 17, 2004
  3. Replies:
    2
    Views:
    507
    Lasse Reichstein Nielsen
    May 22, 2005
  4. Otto Wyss
    Replies:
    0
    Views:
    372
    Otto Wyss
    Jun 8, 2004
  5. Stuart Gerchick
    Replies:
    27
    Views:
    1,924
    Steven T. Hatton
    Nov 12, 2004
Loading...

Share This Page