TROVE-2017-009: Replay-cache ineffective for v2 hidden services.SEVERITY: MediumALSO TRACKED AS: CVE-2017-8819SUMMARY: There's a possibility for a limited replay attack of INTRODUCE2 cells towards a legacy (v2) onion service.BACKGROUND: The hybrid-encryption algorithm we used for v2 onion services is somewhat malleable. To encrypt the message X to a public key PK, clients generate a random AES key K, and then send RSA-OAEP(K || Start-of-X) || AES_CTR(K, End-of-X) But as you'll notice, the AES-encrypted portion is unauthenticated and therefore malleable. It contains a portion of the g^x DH key. What this means is that an attacker who sees a v2 onion service's INTRODUCE1 cell can send a large number of corresponding INTRODUCE2 cells each containing a g^x that differs in the final bits. When the v2 onion service gets one of these altered cells, it will launch a connection to the same rendezvous point as before, with a different g^y, and a different KH. Because of this attack, in 0.2.3.4-alpha, we changed the replay cache so that it checks for replays in the RSA-encrypted (non-malleable) portion. For more info, see tor-spec.txt, section 0.4; rend-spec-v2.txt, sections 1.8 and 1.9.THE PROBLEM: In 471ab34032581e6631c23ee05a2b212e757bafab, when we refactored the v2 onion service code in Tor 0.2.4.1-alpha, we accidentally included this change. The critical part is the change in the length of data added checked: previously, it was only "keylen" -- the length of the RSA key. But now it's the whole ciphertext, when means that a modified version won't get detected as a replay.IMPACT: If an attacker can observe the rendezvous point, they can make the onion service make lots of connections to it -- but any attacker can already do that if they know the onion service's public key by sending their own INTRODUCE1 cells and picking a rendezvous point they control. (And in the v2 hs design, we should assume the attacker already knows the onion service's public key, because of directory crawling attacks.)FIX: Anyone who is running a v2 (old) hidden service should upgrade to one of the releases with the fix for this issue: 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, or 0.3.2.6-alpha.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
TROVE-2017-009: Replay-cache ineffective for v2 hidden services.SEVERITY: MediumALSO TRACKED AS: CVE-2017-8819SUMMARY: There's a possibility for a limited replay attack of INTRODUCE2 cells towards a legacy (v2) onion service.BACKGROUND: The hybrid-encryption algorithm we used for v2 onion services is somewhat malleable. To encrypt the message X to a public key PK, clients generate a random AES key K, and then send RSA-OAEP(K || Start-of-X) || AES_CTR(K, End-of-X) But as you'll notice, the AES-encrypted portion is unauthenticated and therefore malleable. It contains a portion of the g^x DH key. What this means is that an attacker who sees a v2 onion service's INTRODUCE1 cell can send a large number of corresponding INTRODUCE2 cells each containing a g^x that differs in the final bits. When the v2 onion service gets one of these altered cells, it will launch a connection to the same rendezvous point as before, with a different g^y, and a different KH. Because of this attack, in 0.2.3.4-alpha, we changed the replay cache so that it checks for replays in the RSA-encrypted (non-malleable) portion. For more info, see tor-spec.txt, section 0.4; rend-spec-v2.txt, sections 1.8 and 1.9.THE PROBLEM: In 471ab34032581e6631c23ee05a2b212e757bafab, when we refactored the v2 onion service code in Tor 0.2.4.1-alpha, we accidentally included this change. The critical part is the change in the length of data added checked: previously, it was only "keylen" -- the length of the RSA key. But now it's the whole ciphertext, when means that a modified version won't get detected as a replay.IMPACT: If an attacker can observe the rendezvous point, they can make the onion service make lots of connections to it -- but any attacker can already do that if they know the onion service's public key by sending their own INTRODUCE1 cells and picking a rendezvous point they control. (And in the v2 hs design, we should assume the attacker already knows the onion service's public key, because of directory crawling attacks.)FIX: Anyone who is running a v2 (old) hidden service should upgrade to one of the releases with the fix for this issue: 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, or 0.3.2.6-alpha.
Status: assigned to closed Resolution: N/Ato fixed Summary: Fix TROVE-2017-009 to Fix TROVE-2017-009: Replay-cache ineffective for v2 hidden services.