> I'm going to be writing some code that will wind up running on a firewall
> machine. It will be written in C. I am well aware that one of the biggest
> security concerns with running code on a secured host is that code was
> written well. No buffer overruns, etc. It would seem that most problems
> are caused by I/O functions that request data from the user.
Most problems, to be precise, are caused by programs that take unvalidated data
and treat it as if it was safe.
I/O functions really aren't the issue, though they're a common problem.
Eyeball your code, asking yourself "what could someone feed me that would
make this break?" paying particular attention to:
1. I/O routines that don't specify an input buffer size.
2. Conversion routines that don't specify anoutput buffer size.
3. Routines that pass data to other programs.
Routines you should never feed unvalidated data to:
1. gets, scanf, use fgets, etc...
2. strcpy, sprintf, strcat ... use the "n" versions, strncpy, ...
3. system, popen, ... build your pipelines by hand, use execl/execv.
If you're being called from an untrusted environment:
1. Throw away any environment variables you don't understand.
2. Trim the environment variables you do understand.
3. Don't call the "p" variants of exec... you can't trust your path.
4. Assume your command line arguments are unvalidated.
References:
|
|
