[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #24244 [Core Tor/Tor]: Fix TROVE-2017-009: Replay-cache ineffective for v2 hidden services. (was: Fix TROVE-2017-009)

#24244: Fix TROVE-2017-009: Replay-cache ineffective for v2 hidden services.
----------------------------+------------------------------------
 Reporter:  nickm           |          Owner:  nickm
     Type:  defect          |         Status:  closed
 Priority:  Medium          |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor    |        Version:
 Severity:  Normal          |     Resolution:  fixed
 Keywords:  trove-2017-009  |  Actual Points:
Parent ID:                  |         Points:
 Reviewer:                  |        Sponsor:
----------------------------+------------------------------------
Changes (by nickm):

 * status:  assigned => closed
 * resolution:   => fixed


Old description:



New description:

 {{{
 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.

 }}}

--

Comment:

 Fixed in today's releases.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24244#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs