Undoubtedly there are all sorts of languages in the world, yet none of them is without meaning. | |
1 Corinthians 14:10 (NIV) |
There are many language-specific security issues. Many of them can be summarized as follows:
Turn on all relevant warnings and protection mechanisms available to you where practical. For compiled languages, this includes both compile-time mechanisms and run-time mechanisms. In general, security-relevant programs should compile cleanly with all warnings turned on.
Avoid dangerous and deprecated operations in the language. By ``dangerous'', I mean operations which are difficult to use correctly.
Ensure that the languages' infrastructure (e.g., run-time library) is available and secured.
Languages that automatically garbage-collect strings should be especially careful to immediately erase secret data (in particular secret keys and passwords).
Know precisely the semantics of the operations that you are using. Look up operation's semantics in its documentation. Do not ignore return values unless you're sure they cannot be relevant. This is particularly difficult in languages which don't support exceptions, like C, but that's the way it goes.
One of the biggest security problems with C and C++ programs is buffer overflow; see the chapter on buffer overflow for more information. C has the additional weakness of not supporting exceptions, which makes it easy to write programs that ignore critical error situations.
For C or C++ compilations using gcc, use at least the following as compilation flags (which turn on a host of warning messages) and try to eliminate all warnings (note that -O2 is used since some warnings can only be detected by the data flow analysis performed at higher optimization levels):
gcc -Wall -Wpointer-arith -Wstrict-prototypes -O2 |
You may find some auditing tools helpful for finding potential security flaws. Here are a few:
ITS4 from Reliable Software Technologies (RST) statically checks C/C++ code. ITS4 works by performing pattern-matching on source code, looking for patterns known to be possibly dangerous (e.g., certain function calls). It is available free for non-commercial use, including its source code and with certain modification and redistribution rights. One warning; the tool's licensing claims can be initially misleading. RST claims that ITS4 is ``open source'' but, in fact, its license does not meet the Open Source Definition (OSD). In particular, ITS4's license fails point 6, which forbids ``non-commercial use only'' clauses in open source licenses. It's unfortunate that RST insists on using the term ``open source'' to describe their license. ITS4 is a fine tool, released under a fairly generous license for commercial software, yet using the term this way can give the appearance of a company trying to gain the cachet of ``open source'' without actually being open source. RST says that they simply don't accept the OSD definition and that they wish to use a different definition instead. Nothing legally prevents this, but the OSD definition is used by over 5000 software projects (at least all those hosted by SourceForge at http://www.sourceforge.net), Linux distributors, Netscape (now AOL), the W3C, journalists (such as those of the Economist), and many other organizations. Most programmers don't want to wade through license agreements, so using this other definition can be confusing. I do not believe RST has any intention to mislead; they're a reputable company with very reputable and honest people. It's unfortunate that this particular position of theirs leads (in my opinion) to unnecessary confusion. In any case, ITS4 is available at http://www.rstcorp.com/its4.
LCLint is a tool for statically checking C programs. With minimal effort, LCLint can be used as a better lint. If additional effort is invested adding annotations to programs, LCLint can perform stronger checking than can be done by any standard lint. The software is licensed under the GPL and is available from http://lclint.cs.virginia.edu.