QNX resource manager attacks With Secpol enabled
🚨 Two QNX Resource Manager Supplier Attacks: One Detectable, One That Breaks Your Crypto Stack Silently
I ran two supply-chain attacks on a QNX-based system. Both came from a "trusted" Tier-1 binary. Both passed code signing, SBOM scans, and secpol audits. Both deployed through a textbook ISO/SAE 21434-compliant pipeline. Only one is catchable with conventional tooling. The other operates in a structural blind spot that becomes a fleet-scale cryptographic catastrophe the moment it ships.
═══════════════════════════════
🔴 ATTACK #1 — The Trojan Resource Manager (detectable)
A Tier-1 ships a signed QNX resmgr. Clean SBOM. Passes integration. The integrator wires it in, secpol_resmgr_attach() registers /dev/attack, ECU boots green.
Chain: A hidden CLI argument parsed by main() — invisible to manifest review — activates dormant logic. The resmgr becomes a persistent IPC backdoor: every cat /dev/attack is a MsgSend() to attacker code running with full resmgr privileges, capable of MsgSendv() lateral pivots and _IO_CONNECT hijacking of legitimate clients.
Why it matters: A resmgr isn't a driver — it's a privileged API gateway. In zonal architectures brokering CAN, SecOC, and HSM, one trojan resmgr MITMs the entire bus. Catchable with argument-surface contracts, CI fuzzing, and per-supplier secpol allow-lists.
═══════════════════════════════
🔴 ATTACK #2 — a TOCTOU attack against the security policy lifecycle Entropy Poisoning
This is the one that breaks the model.
Supplier & integrator story: Same Tier-1, different binary. No CLI arguments. No undocumented APIs. No suspicious syscalls in isolation. Static analysis green. SBOM green. The integrator does everything right per ISO 21434:
✅ Generates least-privilege policy via QNX secpolgenerate
✅ Defines a tight transition lattice: resmgr_init → run_safe
✅ During init, grants broad allow_attach resmgr_init /... — structurally required, because cmd-line paths vary per supplier and the kernel cannot pre-know the device node
✅ Post-init, narrows to allow_attach run_safe /dev/t_rm only
✅ Policy reviewed, signed, audited
Textbook 21434 §10. Zero protection against this attack.
How it overrides the policy: The binary doesn't violate the policy. It exploits the structural privilege window the policy mandates. secpol enforces spatial isolation — what's permitted now. It has no temporal model of pre-transition behavior. The transition isn't a sandbox boundary — it's a renaming ceremony. Equivalent to setuid dropping privileges after the damage is done. The attacker commits the crime in the past tense, then transitions into compliance.
Chain:
1️⃣ Exploit the resmgr_init window — broad allow_attach /... is structurally required.
2️⃣ Open /dev/random for write — fully legal under resmgr_init ability set. The QNX random resmgr accepts written bytes as entropy contributions (the path hardware RNG drivers use).
3️⃣ Poison the pool with constants: 0x00, 0x44, 0x44... The mixer treats attacker bytes as legitimate entropy. Pool state now has measurable, attacker-controlled bias.
4️⃣ Release descriptor. Call secpol_transition_type(NULL, "run", 0). Drops to run_safe. Indistinguishable from a benign supplier resmgr.
5️⃣ Cryptographic collapse:
cat /dev/random | hd
0000000 4444 4444 4444 4444 4444 4444 4444 4444
This is Dual_EC_DRBG at the OS layer — backdoor the entropy, not the algorithm. Same failure class as Debian OpenSSL CVE-2008-0166 and Heninger "Mining Your Ps and Qs."
Fleet-scale blast radius:
🔑 Secure boot — predictable HSM challenge nonces = forgeable boot
🔑 TLS 1.3 / ISO 15118-2 PnC — predictable ECDHE = full MITM + contract cert forgery
🔑 SecOC freshness — replayable, defeating the entire AUTOSAR threat model
🔑 HSM session keys — predictable = keystore extraction
🔑 EOL provisioning — every vehicle off the line shares the weakness. Fleet-scale key collision.
One poisoned resmgr at one Tier-1 = every key in every vehicle pre-computed at the factory.
What needs to be done:
✅ Split resmgr_init into staged sub-types — init_minimal denies /dev/random writes by policy, during init
✅ HSM-rooted entropy attestation — no key unseals until pool passes NIST SP 800-90B continuous tests (RCT, APT). Treat entropy attestation as critical as binary attestation
✅ Behavioral SBOMs — suppliers declare every syscall, device path, and IPC channel during init; CI fails on drift
✅ Differential binary analysis — any new /dev/* write between supplier versions triggers mandatory TARA review pre-merge
✅ Pre-transition behavioral attestation — the policy framework must record and attest what happened before the transition, not just enforce after
═══════════════════════════════
Hard truth: secpol enforces space, not time. The transition boundary is not the trust boundary. If your CI can't catch a 5-line takeover_random() injected into a supplier resmgr, your UN R155 type approval is built on sand.
#AutomotiveCybersecurity #QNX #ISO21434 #UNR155 #SupplyChainSecurity #SDV #HSM #SecureBoot