Writing Secure C and Secure C Idioms

Question

\"The average man does not want to be free. He simply wants to be safe.\" - H. L. Menken

I am attempting to write very secure C. Below I

Answer 1

1. Reading from a stream

   The fact that getline() "will automatically enlarge the block of memory as needed" means that this could be used as a denial-of-service attack, as it would be trivial to generate an input that was so long it would exhaust the available memory for the process (or worse, the system!). Once an out-of-memory condition occurs, other vulnerabilities may also come into play. The behaviour of code in low/no memory is rarely nice, and very hard to predict. IMHO it is safer to set reasonable upper bounds on everything, especially in security-sensitive applications.

   Furthermore (as you anticipate by mentioning special characters), getline() only gives you a buffer; it does not make any guarantees about the contents of the buffer (as the safety is entirely application-dependent). So sanitising the input is still an essential part of processing and validating user data.

2. sscanf

   I would tend to prefer to use a regular expression library, and have very narrowly defined regexps for user data, rather than use sscanf. This way you can perform a good deal of validation at the time of input.

3. General comments

   • Fuzzing tools are available which generate random input (both valid and invalid) that can be used to test your input handling
   • Buffer management is critical: buffer overflows, underflows, out-of-memory
   • Race conditions can be exploited in otherwise secure code
   • Binary files could be manipulated to inject invalid values or oversized values into headers, so file format code must be rock-solid and not assume binary data is valid
   • Temporary files can often be a source of security issues, and must be carefully managed
   • Code injection can be used to replace system or runtime library calls with malicious versions
   • Plugins provide a huge vector for attack
   • As a general principle, I would suggest having clearly defined interfaces where user data (or any data from outside the application) is assumed invalid and hostile until it is processed, sanitised and validated, and the only way for user data to enter the application