Opened 2 years ago

Closed 19 months ago

Last modified 19 months ago

#5934 closed task (fixed)

Tor relay denial of service

Reported by: runa Owned by:
Priority: normal Milestone:
Component: Tor Version:
Keywords: tor-relay Cc: tichodroma@…, cypherpunks@…
Actual Points: Parent ID:
Points:

Description

From https://lists.torproject.org/pipermail/tor-talk/2012-May/024328.html:

I found a strange behavior in Tor relays that allow me to make a remote Tor relay crash or at least have a 100 % CPU usage. It crashes only if it is possible to send more data than RAM (and swap) can store in 300 s (5 minutes) to the relay.

Proof of concept attached to this ticket. I have not tested this myself.

Child Tickets

Attachments (1)

tor_relay_denial_of_service.txt (2.2 KB) - added by runa 2 years ago.

Download all attachments as: .zip

Change History (10)

Changed 2 years ago by runa

comment:1 Changed 2 years ago by Tichodroma

  • Cc tichodroma@… added

I can't reproduce this bug. I've tested the script against my OR (FF1B886D68DA1750DEB81980E1F7D3C034C5E5DE). There is no observable result on the OR side: no CPU usage increase, no memory consumption.

comment:2 Changed 2 years ago by asn

Not sure what's the idea here.

It seems to me that it simply reaches command_process_cell() and triggers:

  /* Reject all but VERSIONS and NETINFO when handshaking. */
  /* (VERSIONS should actually be impossible; it's variable-length.) */
  if (handshaking && cell->command != CELL_VERSIONS &&
      cell->command != CELL_NETINFO) {
    log_fn(LOG_PROTOCOL_WARN, LD_PROTOCOL,
           "Received unexpected cell command %d in state %s; ignoring it.",
           (int)cell->command,
           conn_state_to_string(CONN_TYPE_OR,conn->_base.state));
    return;
  }

repeatedly (he is sending PADDING cells). I don't see anything CPU-exciting happening there.

I tested it in a remote relay of mine and I didn't notice any kind of high CPU activity.

Maybe he only tried this on localhost and he was getting DoSed by his python process.

comment:3 follow-up: Changed 2 years ago by cypherpunks

  • Cc cypherpunks@… added

It appears to only work on linux with older openssl. does not work on linux with current openssl.

Does not work on freebsd 9, os x 10.7.4, windows 7.

comment:5 in reply to: ↑ 3 Changed 2 years ago by cypherpunks

Replying to cypherpunks:

It appears to only work on linux with older openssl. does not work on linux with current openssl.

Does not work on freebsd 9, os x 10.7.4, windows 7.

Fuck you punk, if you know version of openssl you must say it. What the fuck is "older"? 0.9.8? 0.9.7? 0.9.6? No need more spreading bullshit. hardkor can make itself. I hope you are not the same person.

Except bullshit about DoS over localhost (read the code assholes, find diff between localhost and real world before post shit), it's probably about compression that still working for relays that linked with "older" (as said punk) openssl version.

  /* Don't actually allow compression; it uses ram and time, but the data
   * we transmit is all encrypted anyway. */
  if (result->ctx->comp_methods)
    result->ctx->comp_methods = NULL;

comment:6 Changed 23 months ago by nickm

  • Status changed from new to needs_review

See bug #6007 for the underlying issue here. There's a patch to review there.

comment:7 Changed 19 months ago by nickm

  • Resolution set to fixed
  • Status changed from needs_review to closed

Looks like #6007 got merged. Closing this too.

comment:8 Changed 19 months ago by nickm

  • Keywords tor-relay added

comment:9 Changed 19 months ago by nickm

  • Component changed from Tor Relay to Tor
Note: See TracTickets for help on using tickets.