Difference between revisions of "StarlingX/Security/Banned C Functions"
(Created page with "=== 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...") |
(→Guidance) |
||
| Line 1: | Line 1: | ||
=== Guidance === | === 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: | + | 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: [https://msdn.microsoft.com/en-us/library/bb288454.aspx msdn]). Specifically, for starling X, the main guidelines are that: |
Only functions in the standard C runtime library—libc—are mandated | Only functions in the standard C runtime library—libc—are mandated | ||
Unbounded functions are banned unless specifically noted | Unbounded functions are banned unless specifically noted | ||
Revision as of 21:30, 16 November 2018
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 PSE. requires detailed inspection to avoid va_list pitfalls |
| 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 PSE. requires detailed inspection to avoid stack overflow |
Color Coding
| Allowed w/Inspection | Banned | Banned w/Exceptions |
