search

rustybird / corridor

Tor traffic whitelisting gateway
ISC License
68 stars 6 forks source link

Starting corridor-data crashes Tor #51

Open BCSharp opened 18 hours ago

BCSharp commented 18 hours ago

I'm using Qubes R4.2.3 and installed corridor in a dedicated qube based on template debian-12-xfce following the standard installation instructions.

As soon as service corridor-data is started, service tor@default terminates abnormally with the following stack trace:

tor_assertion_failed_(): Bug: ../src/lib/crypt_ops/crypto_ed25519.c:658: ed25519_pubkey_copy: Assertion src fail>
Bug: Tor 0.4.7.16: Assertion src failed in ed25519_pubkey_copy at ../src/lib/crypt_ops/crypto_ed25519.c:658: . S>
Bug:     /usr/bin/tor(log_backtrace_impl+0x57) [0x5a01a717b0f7] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(tor_assertion_failed_+0x147) [0x5a01a7185f77] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(ed25519_pubkey_copy+0x94) [0x5a01a716ecc4] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(server_onion_keys_new+0x45) [0x5a01a72a2ea5] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(+0x1b4ba7) [0x5a01a7249ba7] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(threadpool_new+0x16b) [0x5a01a72b60bb] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(cpu_init+0xad) [0x5a01a724a13d] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(options_act_relay+0x2b5) [0x5a01a72abf85] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(set_options+0xc68) [0x5a01a72133a8] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(+0x17efef) [0x5a01a7213fef] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(+0x1aa08e) [0x5a01a723f08e] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(handle_control_command+0x320) [0x5a01a723fcf0] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(connection_control_process_inbuf+0x2c2) [0x5a01a723a4e2] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(+0x190df3) [0x5a01a7225df3] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(+0x6c359) [0x5a01a7101359] (on Tor 0.4.7.16 )
Bug:     /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x21585) [0x73841713d585] (on Tor 0.4.7.16 )
Bug:     /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x49f) [0x73841713dc1f] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(do_main_loop+0xf1) [0x5a01a7102661] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(tor_run_main+0x1e5) [0x5a01a70fdfb5] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(tor_main+0x59) [0x5a01a70fa309] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(main+0x19) [0x5a01a70f9ec9] (on Tor 0.4.7.16 )
Bug:     /lib/x86_64-linux-gnu/libc.so.6(+0x2724a) [0x73841684624a] (on Tor 0.4.7.16 )
Bug:     /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x738416846305] (on Tor 0.4.7.16 )
Bug:     /usr/bin/tor(_start+0x21) [0x5a01a70f9f11] (on Tor 0.4.7.16 )

Originally I installed corridor following the instructions from the Whonix Wiki (i.e from the Whonix repository using apt-get), but then I noticed that the head upstream version (i.e. from this repo) is a copule of commits ahead so I tried it instead, alas with the same result.

How to reproduce

Create a standard sys-corridor qube using the standard installation instructions. Boot the qube and check the status of tor@default using systemctl status tor@default. It will be either activating (restarting after crash for several times) or failed.

To better pinpoint the cause of the Tor crash, deactivate Qubes service corridor:

[dom0]$ qvm-service sys-corridor corridor --disable
[dom0]$ qvm-service sys-corridor qubes-firewall --disable

This will prevent corridor from starting on boot, and prevent standard Qubes firewall rules populate the NFT tables (if corridor were started on boot, it would prevent it itself from within the qube, so disabling Qunbes firewall is basically creating the same environment, but unconditionally).

(Re-)start qube sys-corridor and check status of tor@default. After a minute or so, it is fully started and working well.

Now, enable the Qubes service corridor (to meet the precondition of corridor's systemd unit file) and start corridor-data:

sudo touch /var/run/qubes-service/corridor
sudo systemctl start corridor-data

Observe that the tor@default service chashes immediately, tries to restart a few times, and then fails completely.

sudo journalctl -u tor@default will display the stack trace and other error messages.

rustybird commented 12 hours ago

I think the crash (caused by this line, which is there to keep the consensus updated even if nothing else is using tor on the router) was fixed in tor 0.4.8.x. Can you try with the latest release (currently 0.4.8.13) from the Tor Project Debian Repository?

BCSharp commented 2 hours ago

Yes, I updated Tor to 0.4.8.13 and the setup works fine now. Thanks!

Maybe update the installation wiki page or the corridor project README to mention that the minimum requirements is tor 0.4.8.x?