Secure Coding
The secure coding guidelines are an extension to the team's coding guide, CODING.md, with the following additional rules:
Basic Guidelines
- Initialise all variables.
- Validate the input parameters of functions that can be called by another layer/component than the current one.
- Where the size of an output parameter is supplied by an untrusted caller, check that the size is not greater than the available data before copying it to the output parameter. Alternatively, refactor the API to not permit the caller to specify the output size
- Ensure that functions are not called with parameters that will cause buffer overflow inside the function.
- Check the return values of functions.
- Prefer string functions with a strict length limit to avoid memory overruns due to missing closing
0
values (i.e.snprintf
vssprintf
). - Avoid undefined, unspecified and implementation-defined behaviours of the C99 standard.
- Limit the scope of variables to as minimum as possible.
- Limit life-cycle of variable to as minimum as possible.
- Assume code memory is non writable and data memory as non executable.
- Be aware of integer overflows.
- Be aware of side effects of integer promotion. Use type casts to enforce well defined behavior.
- Never rely on operator precedence, always use parentheses to enforce order of evaluation.
- When injecting code fragments using macro definitions, the pre-processed output must be carefully investigated for side effects.
- Use
const
keyword by default unless mutation is required. - Ensure debugging code is not in release builds.
- Treat all warnings as errors
Note
Where possible, all of these rules will be checked automatically by a static analyser.
Deviations of these rules need to be clearly documented and justified.
Banned APIs/Functions
This is the list of banned APIs for the project:
strcpy
wcscpy
strncpy
strcat
wcscat
strncat
sprintf
vsprintf
strtok
atoi
atol
atoll
itoa
ltoa
lltoa
Use of banned APIs will be checked for in the CI.
Coding processes
Code Review
- All contributions must consider the Security Code Review Checklist (detailed below)
Secure Design Guidelines
- Encrypt data at rest
- Ensure that cryptographic modules are not subject to side channel attacks
- Be aware of side-channel attacks
- Take care of Time of Check to Time of Use (TOCTOU) vulnerabilities
- Depending on their configuration, do not trust peripherals
- Apply the principle of least privilege
IOT-OS-M Security Code Review Checklist
This checklist must be considered during the review of any contributions.
Data at rest
Does the patch affect reading or writing data from/to temporary or persistent file systems?
-
[ ] No
-
[ ] Yes, look for code changes that may affect any of the following ...
Consider:
Confidentiality
-
[ ] Encryption of stored data
-
[ ] Protection for cryptographic certificates and keys
-
[ ] Mitigations for directory traversal vulnerabilities
Integrity
-
[ ] Cryptographic hash or signature of the stored data
-
[ ] Management of cryptographic certificates and keys
-
[ ] Random number generation and seeding
-
[ ] Mitigations for TOCTOU vulnerabilities
-
[ ] Mitigations for file I/O race conditions
-
[ ] Defensive mount options for storage
-
[ ] Defensive configuration of USB and other file I/O stacks
Availability
-
[ ] Access controls to storage
-
[ ] Isolation or sandboxing of processes that access removable storage
Data in motion
Does the patch add, remove or alter transmission or reception of data over a network or IPC mechanism?
-
[ ] No
-
[ ] Yes
Does the patch add, remove or alter a client or server process?
-
[ ] No
-
[ ] Yes
If you selected 'Yes' for either, look for code changes that may affect any of the following ...
Consider
Confidentiality
-
[ ] Encryption of transmitted data
-
[ ] Protection for cryptographic certificates and keys
-
[ ] Protection for network and wireless access credentials
-
[ ] Prevention of information leakage through client/server error or status messages
-
[ ] Prevention of exposed MAC addresses and other personal identifiers in network protocols
-
[ ] Prevention of information leakage through padding in data
Integrity
-
[ ] Choice of network protocols and wireless pairing mechanisms
-
[ ] Authentication of clients and servers
-
[ ] Cryptographic hash or signature of transmitted data
-
[ ] Management of cryptographic certificates and keys
-
[ ] Random number generation and seeding
-
[ ] Mitigations for MITM and replay attacks
-
[ ] Defensive configuration of network and other connectivity stacks
-
[ ] Firewall rules
Availability
-
[ ] Access controls to IPC mechanism
-
[ ] Isolation or sandboxing of client/server processes
Data in use
Does the patch add, remove or alter processing of data in memory?
-
[ ] No
-
[ ] Yes, look for code changes that may affect any of the following ...
Consider
Confidentiality
-
[ ] Clearing sensitive data from memory after use
-
[ ] Protection of sensitive data passed to/collected from library functions
-
[ ] Prevention of information leakage through logging or debug output
-
[ ] Prevention of information leakage through string literals in object code
-
[ ] Prevention of information leakage through symbol tables in object code
Integrity
-
[ ] Adherence to secure coding guidelines
-
[ ] Protection against arithmetic over/underflow
-
[ ] Input/argument validation using 'whitelisting'
-
[ ] Verification of new/altered parsing/deserialisation code
-
[ ] Coding mitigations for side channel attacks
-
[ ] Error recovery that creates denial-of-service vulnerabilities (e.g. assertions)
Availability
-
[ ] Process ownership, permissions or capabilities
-
[ ] Process isolation or sandboxing
-
[ ] Software or hardware watchdog