security coding guidelines for C/C++

[Aravind]

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

 

[CBFalconer]

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.

 

[Malcolm]

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.

 

[August Derleth]

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.

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

 

[Christian Bau]

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.

 

[Matthew Jakeman]

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

 

[Arthur J. O'Dwyer]

[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

 

[Paul Hsieh]

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.

 

[Michael Wojcik]

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.

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 (e-mail address removed)

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