Opened 5 weeks ago

Closed 2 weeks ago

#24244 closed defect (fixed)

Fix TROVE-2017-009: Replay-cache ineffective for v2 hidden services.

Reported by: nickm Owned by: nickm
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: trove-2017-009
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

TROVE-2017-009: Replay-cache ineffective for v2 hidden services.

SEVERITY: Medium

ALSO TRACKED AS: CVE-2017-8819

SUMMARY:

  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.

Child Tickets

Change History (1)

comment:1 Changed 2 weeks ago by nickm

Description: modified (diff)
Resolution: fixed
Status: assignedclosed
Summary: Fix TROVE-2017-009Fix TROVE-2017-009: Replay-cache ineffective for v2 hidden services.

Fixed in today's releases.

Note: See TracTickets for help on using tickets.