* Sub-threat: uninitialized kernel stack memory controlled by attacker
* Mitigation: zero-initialize all kernel stack memory before use
* Test: sequentially call 2 functions that allocate the same amount of memory, fill the first with known values and return, and during second function call, read the stack contents back
* Sub-threat: uninitialized kernel heap memory controlled by attacker
* Mitigation: zero-initialize all kernel heap memory before use
* Test: allocate heap memory, fill with a known value, free it, allocate it again in a deterministic way to get the same heap region, and read back the contents
* Result: heap contents are clear on second allocation
* Output: action logged as an event
#### 5.2.X. **MI-KLLP**: Kernel linked list protection
* Sub-threat: kernel doubly linked list corruption
* Mitigation: linked list implementation checks prev/next pointers on add/del
* Test: add or delete an item to an uninitialized list
* Result: thread is killed
* Output: action logged as an event or the OS reboots
#### 5.2.X. **MI-KPXM**: Prevent execution of non-kernel code memory
* Sub-threat: Non-code executable kernel memory
* Mitigation: Only kernel code memory regions are executable
* Test: copy a trivial return-only function into every class of non-code memory in the kernel (e.g. stack, heap, read-only data), one to a thread, and attempt to execute each one
* Result: each thread is killed
* Output: action logged as an event or the OS reboots
#### 5.2.X. **MI-KPWM**: Prevent writes to kernel code and read-only data memory
* Sub-threat: Writable kernel code or read-only memory
* Mitigation: All kernel code memory and non-writable data is read-only
* Test: from separate threads, write to each portion of kernel code
and non-writable data region
* Result: each thread killed
* Output: action logged as an event or the OS reboots
#### 5.2.X. **MI-KPUM**: Prevent unintentional kernel access to unprivileged memory
* Sub-threat: Unexpected access to userspace memory from OS kernel
* Test: in separate kernel threads, read, write, and execute memory regions that are mapped to userspace without going through dedicated userspace memory access routines
* Result: each thread killed
* Output: action logged as an event or the OS reboots
* Test: set resource reference counter to 1 less than maximum representable value, increment it twice
* Result: reference counter does not overflow but resource is pinned
* Output: action logged as an event or the OS reboots
#### 5.2.X.x **MI-KFCI**: Kernel control flow integrity
Use case: laptop, phone, other devices at higher risk of malicious code execution
* Sub-threat: Kernel function pointer and return pointer overwrite
* Mitigation: Protect saved pointers from overwrite via software (e.g. KASan) or hardware (e.g. Pointer Authentication), or validate transitions of expected control flow graph (e.g. KCFI, Shadow Stack)
* Test: Save a kernel function pointer to heap, overwrite it with a different function, make indirect call to the saved function pointer. Repeat but with a return address that was stored to the stack.
* Result: thread is killed
* Output: action logged as an event or the OS reboots
#### 5.2.X.x **MI-KMT**: Kernel memory protection using memory tagging
Use case: laptop, phone, other devices at higher risk of malicious code execution
* Mitigation: Use software or hardware memory tagging feature for kernel memory allocations
* Test: Allocate 2 adjacent memory regions with separate tags. Attempt to read and write memory with a positive offset into trailing region from leading region's tagged pointer. Attempt to read and write with negative offset into leading region using trailing region's tagged pointer. Free a region and read and write to the region using the original tagged pointer.
* Result: segmentation fault, error handling code executed or thread killed under in all test conditions
* Output: error message or log message for killed thread
Implement all relavent mitigations listed in Annex MEMORY-SAFETY-MITIGATIONS
### 5.2.X **TR-LSRE**: Logging of security-relevant events
@@ -1840,13 +1710,145 @@ Description: Firewall for enterprise network
# Annex MEMORY-SAFETY-MITIGATIONS
Memory safety mitigations almost universally have the same Result and Output:
* Result: each involved thread takes a segmentation fault, has error handling code executed, or is terminated under in all test conditions
* Output: error messages or event logged, or the OS reboots
When this is not true, a mitigation-specific Result and Output will be noted.
## Common Memory Safety Mitigations
Many memory safety mitigations apply to both Kernel and Userspace execution environments, and must be protected in both places.
### **MI-SED**: Stack exhaustion detection
* Sub-threat: stack exhaustion causes thread to write beyond end of stack
* Mitigation: validate the limits of the stack
* Test: perform unbounded recursive call to use all stack memory
### **MI-SLBO**: Stack linear buffer overflow detection
* Mitigation: check for allocation state and prevent use of un/re-allocated memory
* Test: allocate heap memory, free it, write to the allocation
### **MI-HFC**: Heap free checking
* Sub-threat: heap free corruption
* Mitigation: validate heap origin on free
* Test: allocate heap, free it twice
* Result: second free is rejected
### **MI-SMZ**: Stack memory zeroing
* Sub-threat: uninitialized stack memory controlled by attacker
* Mitigation: zero-initialize all stack memory before use
* Test: sequentially call 2 functions that allocate the same amount of memory, fill the first with known values and return, and during second function call, read the stack contents back
* Result: stack contents are clear on second call
### **MI-HMZ**: Heap memory zeroing
* Sub-threat: uninitialized heap memory controlled by attacker
* Mitigation: zero-initialize all heap memory before use
* Test: allocate heap memory, fill with a known value, free it, allocate it again in a deterministic way to get the same heap region, and read back the contents
* Result: heap contents are clear on second allocation
### **MI-MWX**: Prevent writes to code and read-only data memory
* Sub-threat: Writable code or intended read-only memory
* Mitigation: All code memory and non-writable data is read-only
* Test: from separate threads, write to each portion of kernel code and non-writable data region
### **MI-LLP**: Linked list protection
* Sub-threat: doubly linked list corruption
* Mitigation: linked list implementation checks prev/next pointers on add/del
* Test: add or delete an item to an uninitialized list
### **MI-RCP**: Reference counter protection
* Sub-threat: reference counter overflow
* Mitigation: bounds check reference counters
* Test: set resource reference counter to 1 less than maximum representable value, increment it twice
* Result: reference counter does not overflow but resource is pinned
### **MI-CFI**: Control flow integrity
Use case: laptop, phone, other devices at higher risk of malicious code execution
* Sub-threat: Function pointer and return pointer overwrite
* Mitigation: Protect saved pointers from overwrite via software (e.g. ASan) or hardware (e.g. Pointer Authentication), or validate transitions of expected control flow graph (e.g. KCFI, Shadow Stack)
* Test: Save a function pointer to heap, overwrite it with a different function, make indirect call to the saved function pointer. Repeat but with a return address that was stored to the stack.
### **MI-MPMT**: Memory protection using memory tagging
Use case: laptop, phone, other devices at higher risk of malicious code execution
* Mitigation: Use software or hardware memory tagging feature for memory allocations
* Test: Allocate 2 adjacent memory regions with separate tags. Attempt to read and write memory with a positive offset into trailing region from leading region's tagged pointer. Attempt to read and write with negative offset into leading region using trailing region's tagged pointer. Free a region and read and write to the region using the original tagged pointer.
FIXME: Stack ASLR
FIXME: Exec ASLR
## Userspace-specific memory safety mitigations
FIXME: Sym-/Hard-Link restrictions
FIXME: FIFO restrictions
FIXME: Libs/mmap ASLR
FIXME: brk ASLR
### Toolchain hardening
FIXME: PIE
FIXME: FORTIFY_SOURCE
FIXME: RELRO (merge below into "binary runtime metadata"?)
FIXME: BIND_NOW (merge above into "binary runtime metadata"?)
FIXME: -fstack-clash-protection (covered by "stack exhaustion"?)
FIXME: -fcf-protection (covered by "CFI"?)
## Kernel provided userspace mitigations
FIXME: vDSO ASLR
FIXME: NULL-address protection
FIXME: ptrace scope
## Kernel-specific memory safety mitigations
FIXME: Module ASLR
FIXME: JIT ASLR
### **MI-KPXM**: Prevent execution of non-kernel code memory
* Sub-threat: Non-code executable kernel memory
* Mitigation: Only kernel code memory regions are executable
* Test: copy a trivial return-only function into every class of non-code memory in the kernel (e.g. stack, heap, read-only data), one to a thread, and attempt to execute each one
### **MI-KPUM**: Prevent unintentional kernel access to unprivileged memory
* Sub-threat: Unexpected access to userspace memory from OS kernel
* Test: in separate kernel threads, read, write, and execute memory regions that are mapped to userspace without going through dedicated userspace memory access routines
# Annex A (informative): Relationship between the present document and any related ETSI standards (if any)
