TROVE-2023-006 vulnerability not yet addressed in Whonix-16?

taran1s · November 19, 2023, 1:33pm

Hi everyone, the TROVE-2023-006 vulnerability, Tor ticket tor#40883, Remote triggerable assert on onion services is available on http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/team/-/wikis/NetworkTeam/TROVE

Bug in is Tor version 0.4.8.1-alpha, Fix in is in Tor version 0.4.8.9.

After the latest Whonix-16 update I can still see the Tor version 4.7.13 that is vulnerable to the TROVE-2023-006. Will the Tor version be updated in the Whonix-16? If not, what steps should be completed to update to the Tor version that fixed the TROVE-2023-006 vulnerability (0.4.8.9)?

gonein5 · November 20, 2023, 12:03pm

It’s not according to Debian’s tracker. See TEMP-0000000-556BB5. It is however still vulnerable to TROVE-2023-004.

See Tor integration in Whonix Development Notes also.

Patrick · November 20, 2023, 2:02pm

It doesn’t make sense for me to stay on Qubes R4.1 / Whonix 16.

related:
Qubes-Whonix Support Schedule

If you want newer Tor versions quicker, see this:

(Whonix is based on Kicksecure.)

If Debian doesn’t fix this then this is unlikely to get fixed.

neo0xff · November 20, 2023, 8:23pm

I noticed you run your own mirror for KickSecure for some packages? Why not we compile Tor that is quicker to update instead of relying strictly on Debian packages as we know are always slow to update?

Patrick · November 21, 2023, 5:36am

I am not doing that to avoid the extraneous maintenance burden.

Whonix 16 is “oldstable”, speak outdated. Its support is only dragged along due to Qubes R4.2 still being RC instead of final. Kinda Qubes “LTS” (“long term support”).

I don’t think “LTS” / two major versions at the same time support is a good idea given the already sparsely available resources.

Development focus in on Whonix 17, where all packages are more upgraded and therefore hopefully be more secure.

If you care about new / sophisticated attacks being addressed / hosting onion services, I don’t think it’s a good idea to stay on “oldstable” / “LTS”.

Hence my previous answer:

Patrick · December 7, 2023, 1:30pm

github.com/QubesOS/qubes-issues

Qubes-Whonix 16 security support / Qubes R4.2 stable release date

opened 01:29PM - 07 Dec 23 UTC

adrelanos

T: bug P: default

Debian is not going to fix a Tor vulnerability for Debian 11 (bullseye). http…s://security-tracker.debian.org/tracker/TEMP-0000000-7CC552 That I take by the table on the Debain website marking the Tor version for that Debian release as "end-of-life". Hence Whonix 16 (Debian 11, bullseye based) won't get the fix either by any Debian package upgrade. It seems and more and more that Qubes-Whonix 16 should be deprecated. Backporting the fix to Whonix 16 be a major hassle and I don't see much point in it either staying on outdated bullseye (what Whonix 16 is based on). That seems that worst solution to me. Qubes 4.2 seems to be stuck in RC land. Now at 4.2.0-rc5. "For a full list of open bug reports affecting 4.2, please see here." https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+label%3Aaffects-4.2+label%3A%22T%3A+bug%22+is%3Aopen There is 161 bugs there. So I doubt these would all be fixed. Also for previously releases there have been tons of bugs there assigned to that release that after the release were ignored. Long story short, what's the ETA for Qubes 4.2? Days, weeks, moths, years? Maybe I should have stayed on Qubes 4.1 and supported Whonix 17 (Debian 12, bookworm based) on Qubes 4.1 only. I didn't expect that Qubes 4.2 release to go up to rc5. Usually rc3 was the last RC before final release if I am not mistaken. If Qubes 4.2 is going to be stuck in RC land for much more time then perhaps Whonix 17 needs to be released for Qubes 4.1 if that is still worth it? Also something that I would like to avoid because it would be clunky to keep testing everything for two different Qubes releases R4.1 and R4.2. Main things to test: * APT does not break due to dependency conflicts * Tor connectivity does not break (and hopefully does not break in weird ways such as it works but fails to download bigger files as in [Tor 0.4.8.9 broken in combination with vanguards](https://gitlab.torproject.org/tpo/core/tor/-/issues/40892). This would also make future development harder such as Whonix port to nftables. (https://github.com/QubesOS/qubes-issues/issues/8562) This is because then I would have to see if Qubes R.4.1 works with nftables, lead test both, etc. Also something I'd rather avoid. Maybe next time I should stay on Qubes stable longer before switching to Qubes RC. So both solutions seem awful (A), effort spent on security support for Debian 11 bullseye Whonix 16 and B) Qubes-Whonix 17 for maybe soon outdated Qubes R4.1) My favorite solution would be Qubes R4.2 to be blessed stable so a Qubes-Whonix 16 deprecation notice can be released.