
Security researchers at V12 discovered two critical vulnerabilities in Signal’s Contact Discovery Service that could allow a malicious server operator to escape the protections of its Intel SGX enclave.
The flaws enabled arbitrary reading of protected enclave memory and, in the more severe case, code execution inside the trusted environment.
V12 researcher Nihal disclosed the findings, after developing working exploits and testing them on real Intel SGX hardware matching the Azure systems used for Signal’s production deployments.
Signal’s Contact Discovery Service, or CDSI, lets users determine which people in their address book also use Signal without exposing the contact list directly to Signal’s servers. The service runs sensitive processing inside an Intel SGX enclave, a hardware-protected execution environment designed to keep data inaccessible even to software controlling the underlying server.
Signal is a widely used encrypted messaging service operated by the nonprofit Signal Technology Foundation. Privacy is central to its design, and CDSI is intended to prevent Signal itself from learning the contents of users’ uploaded address books while still providing contact matching.
The first vulnerability involved how CDSI processes contact database requests across multiple worker threads. The enclave failed to prevent the host from starting more than one worker for the same database shard. A malicious host could exploit the resulting race condition to make the enclave write data into memory that had already been freed and reused.
By carefully controlling that process, V12 turned the bug into an arbitrary memory-read capability. Its proof-of-concept exploit extracted the enclave’s 32-byte Noise responder private key, which could allow the host to impersonate the enclave and decrypt protected queries.
The second flaw affected how CDSI handled client objects. The enclave separately checked whether a client object was valid and then marked it as being used, creating a time-of-check-to-time-of-use race condition. V12 showed that a hostile host could pause execution between those operations, free the legitimate object and replace it with attacker-controlled data.
That replacement could manipulate function pointers used by Signal’s Noise encryption code, ultimately giving the attacker control over the enclave’s CPU register state and allowing code execution inside the protected environment. V12 again demonstrated the impact by extracting the Noise private key.
Signal fixed the shard-worker issue by enforcing a single worker per shard inside the enclave. The client-object vulnerability was addressed by combining its validity check and state tracking into one atomic operation.
Because the weaknesses were in Signal’s server-side enclave code and have already been patched, users do not need to take specific remediation steps. Keeping Signal updated remains advisable, but the fixes themselves were applied to Signal’s infrastructure rather than relying on a client-side update.







Leave a Reply