StarlingX/Security/Banned C Functions

DRAFT

Guidance

Prohibiting the use of banned functions is a good way to remove a significant number of potential code vulnerabilities from C and C++ code. This list is the compiled library of known bad functions that should be removed to reduce vulnerabilities. It is derived from experience with real-world security bugs and focuses primarily on functions that can lead to buffer overruns (reference: msdn).

Specifically, for Starling X, the main guidelines are that:

Only functions in the standard C runtime library—libc—are mandated
Unbounded functions are banned unless specifically noted
Stack allocation functions are banned unless specifically approved by the project core

There is no requirement to retrofit existing upstream code to meet these guidelines. A summary of the policy is provided below.


Func	Status
strcpy, wcscpy	unbounded, banned; use strncpy
strncpy	inspect for unterminated/truncated output
strcat, wcscat	unbounded, banned; use strncat
strncat	inspect for truncated output
sprintf, vsprintf	unbounded, banned; use snprintf, vsnprintf
snprintf	inspect for result fitting in buffer: snprintf(buf, size, ...) < size
vsnprintf	banned except with approval from core. requires detailed inspection to avoid va_list pitfalls. vsnprint() is typically used for custom logging functionality. Given the flexibility of this function, it is easy to mismatch data types pushed on the stack for a va-list function and types pulled from the stack by the function. The core needs to ensure that the format matches the variables passed to avoid mismatches.
strtok	unbounded, banned; use strtok_r or strsep
strtok_r, strsep	Inspect for terminated input buffer
sscanf, vsscanf	unbounded, banned
gets	unbounded, banned, use fgets() instead
ato*	banned, use equivalent strto* functions
*toa	Non-standard, inspect for output buffer length; prefer snprintf
strlen, wcslen	banned except static strings; use strnlen with max length constant
memcpy, memmove	allowed
alloca	banned except with approval of core. Requires detailed inspection to avoid stack overflow. In general, it is preferable to allocate from the heap using alloc(). alloca() returns a pointer to a buffer located on the current thread's stack vs. the heap like malloc(). It's often used in cases where performance is especially important, but data length is unknown beforehand, because allocation is a simple matter of moving the stack pointer for the currently executing function. The dangers of using alloca() are stack space exhaustion or a buffer overflow which corrupts local variables. If alloca() is used, the designer needs to understand that: alloca() makes no guarantees about alignment and in most cases provides no overflow canaries that may exist in heap buffers Never use alloca() in a loop where the bounds are not known beforehand. There is no ability to free memory allocated with alloca() unless you return from the function. If a long function continually calls alloca() in a loop, there is a high risk of stack exhaustion. The conversion of alloca() to malloc() or calloc() requires a free() calls to be added as well

Color Coding


Allowed w/Inspection	Banned	Banned w/Exceptions