Tor 0.4.9.12. TROVE, pamięć i koniec TAP na relayach
8 września 2026 Tor Project wypuścił stabilne 0.4.9.12 jako wydanie bezpieczeństwa. Dzień później ta sama wersja weszła do Tor Browser 15.0.22. Nie ma tu mapy cebul ani listy forów. Jest infrastruktura: klient, relay, directory cache i kilka błędów, które w złym momencie kończą się crashiem albo złym stanem procesu.
TROVE to wewnętrzna numeracja podatności projektu (Tor Review of Vulnerabilities and Exploits). W changelogu 0.4.9.12 wracają m.in. TROVE-2026-043, 034, 036, 042 oraz TROVE-2026-032, opublikowany też jako CVE-2026-87724.
Co poszło nie tak w kodzie
Najcięższa klasa problemów siedziała w obsłudze braku pamięci głęboko w kolejkach obwodów. Proces mógł zwalniać obiekty w nieoczekiwanym miejscu stosu i wpadać w use-after-free. Nowe wydanie przenosi reakcję na OOM wyżej: niskopoziomowe ścieżki mają tylko wykrywać stan, nie sprzątać agresywnie w środku krytycznej ścieżki.
Osobno: wrogi directory cache mógł przekonać klienta, że wybrane mikropisy lub deskryptory relayów są bezużyteczne (TROVE-2026-034). Przy włączonym AutomapHostsOnResolve, zwłaszcza z IPv4 albo małymi zakresami VirtualAddrNetwork, pojawiał się kolejny UAF (TROVE-2026-036). Rozmiar consensus diffów ograniczono w bajtach i w liniach, żeby utrudnić DoS przez wyczerpanie pamięci (TROVE-2026-042).
CVE-2026-87724 (TROVE-2026-032) dotyczy congestion control: klient interpretował rozszerzenie CC_RESPONSE nawet wtedy, gdy wcześniej nie wysłał CC_REQUEST. Stan kontroli zatorów psuł się na tyle, że dało się zdalnie doprowadzić do crasha. CVSS w publicznych zapisach to okolice 6.5: nie root na boxie, ale zdalne padnięcie procesu, który ma trzymać obwody.
W tym samym pakiecie poprawiono negocjację kryptografii CGO / congestion control na kolejnych hopach, nie tylko na ostatnim. Dla operatora brzmi to jak detal protokołu. Dla sieci oznacza mniej sytuacji, w których nowsze zabezpieczenia nie dogadują się w połowie ścieżki.
TAP: kto nie zaktualizuje relaya, wypada z konsensusu
Oprócz łat pamięciowych jest twardszy komunikat operacyjny. Directory authorities nie będą przyjmować descriptorów relayów, które nadal niosą klucze TAP. Relay na starej gałęzi ryzyka nie tylko własnymi bugami. Ryzykuje wycięciem z sieci, gdy authorities zaczną odrzucać legacy.
Dla kogoś z Tor Browserem na desktopie ścieżka jest prosta: aktualizacja przeglądarki ciągnie 0.4.9.12. Dla kogoś, kto trzyma relay, bridge albo własny tor jako usługę systemową, liczy się paczka dystrybucji albo build ze źródeł. Klienci na starym daemonie też powinni wejść na poprawione wydanie, zanim ktoś zacznie celować w znane TROVE z changelogu.
Pakiety w repozytoriach Linuksa czasem spóźniają się o dni. Security release projektu i paczka w dystrybucji to nie zawsze ten sam dzień. Kto utrzymuje węzeł „bo działa od roku”, powinien sprawdzić numer wersji, nie tylko uptime.
Co z tego wynika poza changelogiem
Tor w dzienniku pojawia się zwykle jako warstwa prywatności albo tło historii bazarów. Tu widać drugą twarz: to oprogramowanie sieciowe z kolejkami, OOM i negocjacją rozszerzeń przy handshake. Wróg nie musi oznaczać służb celujących w deanonymizację użytkownika. Wystarczy złośliwy cache, ciśnienie pamięci albo zły ciąg rozszerzeń CC, żeby proces padł albo uwierzył w fałszywy stan descriptorów.
Nie rozpisuję wektorów krok po kroku. Project i tak wrzucił poprawki i ostrzeżenie dla operatorów. Sens dla czytelnika jest prostszy: kto polega na Torze jako na infrastrukturze (przeglądarka, relay, most), traktuje security release jak patch firewallowy, nie jak opcjonalny changelog z forum.
W wcześniejszym tekście o Torze pisałem o warstwach i o tym, czego sieć nie obiecuje. Tu dokładam tylko jedną rzecz: warstwa też ma CVE i harmonogram aktualizacji. Anonimowość nie zastąpi patcha.
Jeśli trzymasz relay: 0.4.9.x stable bez TAP w descriptorze. Jeśli czytasz tylko przez Tor Browser: weź 15.0.22 albo nowszy. Reszta to higiena węzła, nie magia cebuli.