defending-firmware.md (2595B)
1 +++ 2 title = 'Defending firmware' 3 +++ 4 5 # Defending firmware 6 Why is it difficult? 7 Lots of design constraints, so "low-hanging fruit" defenses may be omitted, and there might be unclear error handling strategies (you might not be able to rely on someone restarting the system). 8 Also, fragmented development process → unclear security guarantees, difficult patching process, reporting nightmare. 9 Finally, missing entropy sources for randomness, so security things (e.g. crypto) relying on entropy might be bypassable. 10 11 Traditional defenses: 12 - non-executable memory (NX): 13 - standard feature in modern MMUs - but embedded systems may not have MMU 14 - embedded "solution" is memory protection unit (MPU), with basic memory region protection features 15 - ASLR 16 - implementations assume virtual address space, not possible without MMU 17 - firmware often in ROM, so can't randomize for every execution, and compile-time randomization doesn't have same guarantees 18 - MMIO & ROM & RAM at fixed addresses 19 - stack canaries 20 - increases code size, stack size, run time -- direct opposition to design 21 - typically static values, so simple to bypass 22 23 Adoption in practice: 24 - type-I firmware (based on general-purpose OS) mostly deploy standard defenses 25 - type-II firmware (based on custom embedded OS) rarely deploy standard defenses 26 - MMU/MPU not commonly available 27 28 Recent defenses: 29 - static binary sanitization: 30 - static instrumentation to detect corruptions to enable fuzzing 31 - based on static disassembly & binary rewriting 32 - detects: null pointer deref, stack-based buffer overflow, heap buffer overflow, format string, double free 33 - significant runtime and size increase 34 - return address integrity: 35 - compiler-based backward-edge CFI 36 - protects against overwriting return addresses, implemented on top of LLVM 37 - requires MPU and exclusive general purpose register 38 - table of return targets stored in RX memory, function ID stored in exclusive register, and ID is generated with call site-specific function key 39 - little runtime overhead, but increase in size 40 - operation execution integrity 41 - based on remote attestation 42 - detects control-flow hijacking and critical data corruption 43 - requires TrustZone for: measurement of control flow transfers and forwarding to verifier, storing copies of protected data 44 - HERA/hotpatching 45 - not all firmware can be updated, patched firmware could have undesired side-effects 46 - hotpatching means deploying patches while running 47 - HERA -- uses flash patch and breakpoint unit (FPB), lets you divert control flow at specific addresses