Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #24244

Closed (moved)
Open
Opened Nov 11, 2017 by Nick Mathewson@nickm🥄

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

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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.3.3.x-final
Milestone
Tor: 0.3.3.x-final
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#24244