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

[tor-talk] Tor 0.2.2.34 crashes



Hello tories,

after reading this mail I started to upgrade my two tor nodes which ran stable for years. I never have seen my tor process disappearing from the process list. Unfortunamtely, after upgrading to 2.2.34 on both nodes tor is crashing within a short time.

I started tor in debug mode sending its debug log into a file. The crash always happens at the same point.

root@h1896303:/chroot/tor/log# tail debug.log.2
Nov 01 19:52:13.842 [debug] connection_or_process_cells_from_inbuf(): 129: starting, inbuf_datalen 512 (0 pending in tls object).
Nov 01 19:52:13.842 [debug] relay_lookup_conn(): found conn for stream 62648.
Nov 01 19:52:13.843 [debug] circuit_receive_relay_cell(): Sending away from origin.
Nov 01 19:52:13.843 [debug] connection_edge_process_relay_cell(): Now seen 239 relay cells here (command 2, stream 62648).
Nov 01 19:52:13.843 [debug] connection_edge_process_relay_cell(): circ deliver_window now 999.
Nov 01 19:52:13.843 [debug] connection_or_process_cells_from_inbuf(): 129: starting, inbuf_datalen 0 (0 pending in tls object).
Nov 01 19:52:13.843 [debug] conn_read_callback(): socket -1 wants to read.
Nov 01 19:52:13.843 [debug] fetch_from_buf_http(): headerlen 186, bodylen 0.
Nov 01 19:52:13.843 [debug] directory_handle_command_get(): Received GET command.
Nov 01 19:52:13.843 [debug] directory_handle_command_get(): rewritten url as '/tor/status-vote/current/consensus/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB.z'.


My tor runs in a chrooted environment. Together with tor I upgraded libevent to the latest release (2.0.15).

Any ideas? Where can I start searching the bug?

Thanks for any hint in advance

Thomas






Am Freitag, 28. Oktober 2011 schrieb Roger Dingledine:
> Tor 0.2.2.34 fixes a critical anonymity vulnerability where an attacker
> can deanonymize Tor users. Everybody should upgrade.
> 
> The attack relies on four components: 1) Clients reuse their TLS cert
> when talking to different relays, so relays can recognize a user by
> the identity key in her cert. 2) An attacker who knows the client's
> identity key can probe each guard relay to see if that identity key
> is connected to that guard relay right now. 3) A variety of active
> attacks in the literature (starting from "Low-Cost Traffic Analysis
> of Tor" by Murdoch and Danezis in 2005) allow a malicious website to
> discover the guard relays that a Tor user visiting the website is using.
> 4) Clients typically pick three guards at random, so the set of guards
> for a given user could well be a unique fingerprint for her. This
> release fixes components #1 and #2, which is enough to block the attack;
> the other two remain as open research problems.
> 
> Special thanks to "frosty_un" for reporting the issue to us! (As far
> as we know, this has nothing to do with any claimed attack currently
> getting attention in the media.)
> 
> Clients should upgrade so they are no longer recognizable by the TLS
> certs they present. Relays should upgrade so they no longer allow a
> remote attacker to probe them to test whether unpatched clients are
> currently connected to them.
> 
> This release also fixes several vulnerabilities that allow an attacker
> to enumerate bridge relays. Some bridge enumeration attacks still
> remain; see for example proposal 188.
> 
> https://www.torproject.org/download/download
> 
> Changes in version 0.2.2.34 - 2011-10-26
>   o Privacy/anonymity fixes (clients):
...
...

Attachment: signature.asc
Description: This is a digitally signed message part.

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