[tor-commits] [tor/release-0.2.6] Block multiple introductions on the same intro circuit.

[nickm at torproject.org]

commit 8dba8a088d7c1402831ab5a7211a4a347a60ff7a
Author: George Kadianakis <desnacked at riseup.net>
Date:   Wed Apr 1 14:33:09 2015 +0100

    Block multiple introductions on the same intro circuit.
---
 changes/bug15515 |    4 ++++
 src/or/or.h      |    3 +++
 src/or/rendmid.c |   13 +++++++++++++
 3 files changed, 20 insertions(+)

diff --git a/changes/bug15515 b/changes/bug15515
new file mode 100644
index 0000000..dda7c2f
--- /dev/null
+++ b/changes/bug15515
@@ -0,0 +1,4 @@
+  o Minor features (DoS-resistance):
+    - Make it harder for attackers to overwhelm hidden services with
+      introductions, by blocking multiple introduction requests on the
+      same circuit. Resolves ticket #15515.
diff --git a/src/or/or.h b/src/or/or.h
index 34f055c..4459957 100644
--- a/src/or/or.h
+++ b/src/or/or.h
@@ -3157,6 +3157,9 @@ typedef struct or_circuit_t {
    * to the specification? */
   unsigned int remaining_relay_early_cells : 4;
 
+  /* We have already received an INTRODUCE1 cell on this circuit. */
+  unsigned int already_received_introduce1 : 1;
+
   /** True iff this circuit was made with a CREATE_FAST cell. */
   unsigned int is_first_hop : 1;
 
diff --git a/src/or/rendmid.c b/src/or/rendmid.c
index 1bd11f6..2f75ffb 100644
--- a/src/or/rendmid.c
+++ b/src/or/rendmid.c
@@ -149,6 +149,19 @@ rend_mid_introduce(or_circuit_t *circ, const uint8_t *request,
     goto err;
   }
 
+  /* We have already done an introduction on this circuit but we just
+     received a request for another one. We block it since this might
+     be an attempt to DoS a hidden service (#15515). */
+  if (circ->already_received_introduce1) {
+    log_fn(LOG_PROTOCOL_WARN, LD_REND,
+           "Blocking multiple introductions on the same circuit. "
+           "Someone might be trying to attack a hidden service through "
+           "this relay.");
+    goto err;
+  }
+
+  circ->already_received_introduce1 = 1;
+
   /* We could change this to MAX_HEX_NICKNAME_LEN now that 0.0.9.x is
    * obsolete; however, there isn't much reason to do so, and we're going
    * to revise this protocol anyway.