Azure Sphere Unsigned Code Execution Vulnerability

An attacker who has already compromised an Azure Sphere application (the assumed attack surface per the Azure Sphere Security Research Challenge) can exploit the `READ_IMPLIES_EXEC` personality to bypass the platform's write-XOR-execute memory protection. By using ROP gadgets to call `personality()` with `READ_IMPLIES_EXEC` and then invoking the `brk` syscall (or a `malloc` that triggers `brk`), the attacker causes the heap to be allocated with execute permissions. The attacker can then copy shellcode into the now-executable heap region and jump to it, achieving unsigned code execution [ref_id=1].

The vulnerability lies in the Azure Sphere Linux kernel's custom LSM hooks, which only intercept `mmap` and `mprotect` calls (`azure_sphere_mmap_file`, `azure_sphere_file_mprotect`) but do not hook the `brk` syscall path. The `do_brk` function in the kernel uses the `VM_DATA_DEFAULT_FLAGS` macro, which includes `VM_EXEC` when the `READ_IMPLIES_EXEC` personality is set, without any Azure Sphere-specific check [ref_id=1].

The advisory does not include a patch diff, but the root cause is clear: the Azure Sphere LSM hooks only cover `mmap` and `mprotect`, leaving the `brk` syscall path unguarded. The remediation would require either extending the LSM to also intercept `brk`-based allocations when `READ_IMPLIES_EXEC` is set, or preventing the `READ_IMPLIES_EXEC` personality from being applied within Azure Sphere processes. Microsoft released a fix in a later Azure Sphere update (20.06 was the tested version) [ref_id=1].

The advisory provides a proof-of-concept in C (which would be implemented via ROP gadgets in a real attack): call `personality(personality(-1) | READ_IMPLIES_EXEC)`, then use the `brk` syscall (syscall 45) to extend the heap, copy shellcode into the new heap region, and execute it via a function pointer [ref_id=1].