Podatności Zebra

Zebra zebrad 4.4.0 i zebra-script 6.0.0 nie egzekwują reguły konsensusu ZIP-244, akceptując przezroczyste wejścia V5 podpisane z SIGHASH_SINGLE, które nie mają odpowiadającego wyjścia. Atakujący może rozgłaszać spreparowane transakcje V5 z większą liczbą wejść niż wyjść, które Zebra akceptuje, ale zcashd odrzuca, powodując rozdzielenie konsensusu sieci.

ZcashFoundation Zebra zebra-rpc w wersjach przed 8.0.0 i zebrad przed 4.5.0 zawierają osiągalne asercje w handlerze RPC z_listunifiedreceivers, który wywołuje expect() przy parsowaniu odbiorcy Sapling, co kończy się niepowodzeniem dla Unified Addresses zawierających nieprawidłowe punkty Jubjub. Uwierzytelnieni klienci RPC mogą przesłać taki adres, aby przerwać proces zebrad, wielokrotnie utrzymując węzeł offline.

Zebra w wersji przed 6.0.0 zawiera podatność typu denial of service, która pozwala nieuwierzytelnionym peеrом blokować wątki Tokio poprzez przesyłanie transakcji do mempoola wymagających kosztownej synchronicznej weryfikacji skryptów. Atakujący może wysyłać niestandardowe transakcje P2SH o wysokiej liczbie sigop, które docierają do CachedFfiTransaction::is_valid() przed sprawdzeniami standardowości, nasycając bufor weryfikatora i czyniąc węzeł nieodpowiadającym.

Zebra zebrad 4.5.0 i zebra-script 7.0.0 liczą operacje podpisu skryptu redeem P2SH w trybie legacy zamiast dokładnego trybu P2SH zcashd, przeliczając CHECKMULTISIG poprzedzony OP_1 do OP_16 jako 20 sigopów i powodując rozbieżność konsensusu. Zdalni atakujący mogą rozgłaszać wydatki P2SH używające skryptów redeem multisig o niskim progu, tak że blok akceptowany przez zcashd przekracza zawyżony licznik MAX_BLOCK_SIGOPS Zebry, powodując odrzucenie go przez węzły Zebra i zatrzymanie ich poza łańcuchem.

Zebra (zebrad) w wersjach od 5.0.0 do przed 6.0.0-rc.0 nie stosuje limitu przyjęć mempool na peer do transakcji otrzymywanych jako bezpośrednie wiadomości P2P tx, ponieważ są one kolejkowane bez zapisania wysyłającego peera jako źródła. Zdalny przychodzący peer może wysłać wiele unikalnych transakcji, zajmując nieproporcjonalną część miejsc przyjęć mempool, wypierając uczciwe przekaźniki transakcji innych peerów.

Zebra przed wersją 6.1.0 zawiera podatność nieefektywnej złożoności algorytmicznej w funkcji remaining_transaction_value, która klonuje całą mapę wydanych UTXO na poziomie bloku dla każdej transakcji podczas weryfikacji kontekstowej. Atakujący mogą wydobyć lub zasiać mempool około 26 000 minimalnych transakcji z jednym wejściem w jednym bloku, zatrzymując każdy walidujący węzeł na ponad 52 sekundy.

ZcashFoundation Zebra przed wersją 6.1.0 zawiera podatność wyczerpania zasobów, która pozwala nieuwierzytelnionym peerom na degradację przetwarzania bloków poprzez wysyłanie transakcji z nieprawidłowymi dowodami Orchard bez otrzymania punktów kar. Atakujący mogą wielokrotnie wysyłać nieprawidłowe dowody do wspólnego weryfikatora halo2, zmuszając uczciwe dowody bloków do wolnej ścieżki indywidualnej weryfikacji i spowalniając przetwarzanie bloków około siedmiokrotnie.

Zebra (zebrad) w wersji przed 6.2.1 zawiera asymetryczną podatność zużycia zasobów, która pozwala nieuwierzytelnionym peеrом blokować weryfikację bloków poprzez przesyłanie transakcji V6 do mempoola z nieprawidłowymi dowodami Halo2. Atakujący może zalać współdzieloną kolejkę weryfikacji Halo2 bez priorytetu transakcjami o zerowej opłacie z wypełnionymi zerami dowodami Orchard i Ironwood, powodując opóźnienie węzłów względem końca łańcucha.

Zebra przed wersją 6.2.1 zawiera podatność niepełnego czyszczenia, która pozwala nieuwierzytelnionym peerom na blokowanie pobierania prawidłowych bloków poprzez pozostawianie odrzuconych hashów w SentHashes. Atakujący mogą wysłać kontekstowo nieprawidłowy blok, który ma ten sam hash nagłówka co uczciwy blok, powodując, że Request::KnownBlock pomija uczciwy blok i utrzymuje węzły za szczytem.

ZEBRA, węzeł Zcash napisany w Rust, przed wersją 4.5.0 może zaakceptować blok, który zcashd odrzuca z powodu niedoszacowania licznika operacji podpisu P2SH dla skryptów zawierających wyłączony opcode. Atakujący może wykorzystać to do spowodowania rozłamu łańcucha, co wpływa na integralność i dostępność sieci.

W Zebra przed wersją 6.4.0 wykryto podatność polegającą na nieprawidłowej walidacji integralności w ścieżce pobierania przychodzących danych gossip. Pozwala ona nieuwierzytelnionym peerom na wymuszenie odrzucania nowych bloków bez kary. Atakujący mogą dostarczyć prawdziwy blok z przepisanym scriptSig coinbase na wysokość 1, co zachowuje hash bloku ZIP-244, powodując odrzucenie bloku przed walidacją konsensusu i opóźniając odkrycie tipu dla backendów wydobywczych.

W Zebra przed wersją 6.4.0 wykryto podatność polegającą na niekontrolowanym zużyciu zasobów, która pozwala nieuwierzytelnionym peerom na wymuszenie pełnej weryfikacji dowodów poprzez dostarczanie sfałszowanych ciał bloków z prawidłowymi hashami nagłówków. Atakujący mogą zmieniać bajty autoryzujące, takie jak scriptSig coinbase, marnując weryfikację dowodów Sapling, Orchard i Ironwood bez kary, co powoduje zatrzymanie synchronizacji na 67 sekund.

Zebra 2.3.0 przed 6.4.0 zawiera usterkę mechanizmu ochronnego, która pozwala nieuwierzytelnionym użytkownikom na obchodzenie blokad. Blokady i wskaźniki złego zachowania opierają się na dokładnych adresach IP, więc atakujący mogą łączyć się ponownie z nowych adresów IPv6 w swoim alokowanym /64 lub wyczyścić listę blokad FIFO (20 000 wpisów), aby przywrócić dostęp zbanowanym użytkownikom.

ZcashFoundation Zebra 6.4.0 przed 6.4.2 parsuje transakcje wersji 6 z przed-NU6.3 identyfikatorem gałęzi konsensusu, ale obliczanie rozmiaru podczas konstrukcji UnminedTx traktuje ponowną serializację pakietu Orchard jako nieomylną, więc wynikowy błąd powoduje expect, który przerywa działanie zebrad. Nieuwierzytelnieni rówieśnicy mogą wysłać pojedynczą wiadomość tx przed uzgodnieniem (pre-handshake), aby zawiesić węzeł, i mogą to powtarzać po każdym restarcie.

Zebra w wersji przed 4.4.0 zawiera podatność rozbieżności konsensusu w weryfikacji przezroczystych sygnatur V5, obliczając skrót ZIP-244 dla wejść SIGHASH_SINGLE bez odpowiadających wyjść zamiast zgłosić błąd. Atakujący może tworzyć transakcje V5 z mniejszą liczbą wyjść niż wejść, które Zebra akceptuje i szablonuje przez getblocktemplate, produkując bloki odrzucane przez zcashd.

Zebra przed wersją 4.5.0 zawiera podatność niekontrolowanego zużycia zasobów, która pozwala zdalnym rówieśnikom P2P wyczerpać wątki puli blokującej poprzez wysyłanie nadmiernie dużych wektorów lokalizatorów bloków. Atakujący mogą wysyłać wiadomości getblocks lub getheaders z maksymalnie 65 535 haszami lokalizatorów, co powoduje wyszukiwania łańcucha dla każdego hasza i pogarsza wydajność walidacji bloków, RPC i mempool.

Zebra przed wersją 6.3.0 zawiera nieprawidłową obsługę wyjątkowych warunków w funkcji ChainSync::obtain_tips, która odrzuca poprawne odpowiedzi FindBlocks z jednym hashem, fałszywie zgłaszając status blisko szczytu. Peery zwracające tylko następny hash bloku powodują zerową próbkę synchronizacji, przez co punkt końcowy /ready zwraca 200 OK, podczas gdy węzeł pozostaje w tyle za szczytem.

Zebra przed wersją 6.1.0 zawiera podatność niepełnego czyszczenia w zadaniu zapisu stanu, która pozwala zdalnym nieuwierzytelnionym peerom na zatrzymanie synchronizacji węzła poprzez zatrucie parent_error_map. Atakujący mogą dostarczyć blok z manipulowanym coinbase, który ma ten sam hash co kanoniczny blok, zanim ten się rozprzestrzeni, powodując odrzucenie następnego kanonicznego bloku i zatrzymanie węzła na około 2000 bloków.

Zebra przed wersją 6.1.0 zawiera podatność nieprawidłowego obliczenia w selektorze szablonów bloków ZIP-317, która pomija rozmiar nagłówka i liczbę transakcji z budżetu bloku. Atakujący mogą umieścić ważne wybieralne transakcje w mempool ofiary-górnika, aby ukształtować szablony w nadmiernie duże bloki, co powoduje odrzucenie i marnowanie pracy proof-of-work.

Ścieżka pobierania synchronizacji bloków w Zebra (zebrad) w wersji przed 6.3.0 odczytuje wysokość bloku z niezwalidowanego scriptSig coinbase i odrzuca bloki, które wydają się zbyt daleko za końcem łańcucha, przed walidacją konsensusu, bez karania dostarczającego peera. Ponieważ identyfikatory transakcji V5 wykluczają scriptSig, złośliwy peer może wielokrotnie dostarczać kanoniczny blok, którego coinbase twierdzi, że ma wysokość 1, zachowując żądany hash, opóźniając odkrycie najnowszego bloku przez węzeł.

Zebra przed wersją 6.3.0 zawiera awarię mechanizmu ochrony, która pozwala nieuwierzytelnionym peerom na unikanie punktów kar za złe zachowanie poprzez dostarczanie nieprawidłowych bloków plotkowanych. Krok czyszczenia przychodzących błędnie rzutuje RouterError na VerifyBlockError i odrzuca wynik, więc atakujący mogą wielokrotnie wymuszać pobieranie bloków i weryfikację Equihash bez zablokowania.

Zebra (zebrad) w wersjach od 4.5.0 do przed 6.3.0 odrzuca informację o tym, który peer dostarczył hashe bloków w odpowiedziach FindBlocks, a następnie przypisuje 100 punktów kar, czyli próg banowania, temu peerowi, który serwuje żądany blok ponad 50 000 wysokości powyżej szczytu. Zdalny peer może zwrócić prawdziwe hashe z dużej odległości do synchronizującego węzła, aby uczciwe peery zostały zbanowane, co osłabia zestaw peerów i zwiększa ryzyko zaćmienia.

ZEBRA (węzeł Zcash) przed wersją 4.5.0 ma podatność na zdalne zatrzymanie przez nieuwierzytelnionego peera IPv4. Poprzez wykonanie uzgadniania P2P i reklamowanie nieprawidłowej transakcji mempool, atakujący może doprowadzić do asercji w kodzie, co skutkuje przerwaniem działania węzła (panic/abort). Problem naprawiono w wersji 4.5.0.

ZEBRA przed wersją 4.5.0 może zostać zatrzymany przez złośliwego producenta bloków, który umieszcza tę samą transakcję shieldowaną w bloku nadrzędnym i podrzędnym. Asercja o unikalności transakcji w łańcuchu jest osiągalna przed walidacją kontekstową, a wersje release używają panic=abort, co kończy proces.

ZEBRA przed wersją 4.5.0 może zostać trwale zatrzymany przez konsensusowo ważny blok zawierający długi łańcuch transparentnych self-spendów. Kolejność kredytów przed debetami może spowodować przekroczenie MAX_MONEY, co prowadzi do paniki w wersji release. Blok jest akceptowany przez zcashd, więc zatrzymanie utrzymuje się po restarcie.

ZEBRA przed wersją 4.5.0 może być spowolniony przez złośliwego peera P2P, który odpowiada na żądania getblocks/FindBlocks małą listą i serwuje blok z coinbase height znacznie powyżej lokalnego tipa. Błąd nie jest przypisywany do peera, co powoduje anulowanie pobrań i 67-sekundowe opóźnienie synchronizacji. Peer nie jest oceniany ani rozłączany, więc może powtarzać atak.

ZEBRA przed wersją 4.5.0 ma podatność na zablokowanie węzła przez zdalnego, nieuwierzytelnionego peera P2P. Atakujący może wysłać nieprawidłowe ciało bloku, które ma ten sam hash co prawidłowe ciało, co powoduje, że węzeł odrzuca później prawidłowe ciało i pozostaje w tyle o jeden blok aż do restartu lub reorganizacji. Problem naprawiono w wersji 4.5.0.

ZEBRA to węzeł Zcash napisany w języku Rust. Przed wersją 4.5.0 nieuwierzytelniony peer P2P może spowodować, że potok pobierania mempoola będzie przechowywał transakcje po przekroczeniu limitu czasu RATE_LIMIT_DELAY. W rezultacie wpisy cancel_handles nie są usuwane po przekroczeniu limitu czasu, co prowadzi do niekontrolowanego wzrostu pamięci i może doprowadzić do awarii węzła.

ZEBRA to węzeł Zcash napisany w języku Rust. Przed wersją 4.5.0 naturalny lub wywołany przez atakującego fork łańcucha może pozostawić nieaktualne korzenie poddrzew zobowiązań Sapling i Orchard w stanie węzła. Te nieaktualne dane mogą zostać zapisane do RocksDB i przetrwać restarty, co prowadzi do błędnych odpowiedzi dla klientów takich jak lightwalletd.

ZEBRA to węzeł Zcash napisany w języku Rust. Przed wersją 4.5.0 jeden nieuwierzytelniony peer P2P może zmonopolizować wszystkie 25 slotów MAX_INBOUND_CONCURRENCY w potoku pobierania i weryfikacji mempoola. Atakujący może reklamować fałszywe identyfikatory transakcji i blokować sloty, co prowadzi do odrzucania uczciwych transakcji i lokalnych żądań sendrawtransaction.

ZEBRA to węzeł Zcash napisany w języku Rust. Przed wersją 4.5.0 atakujący z uwierzytelnieniem do włączonego punktu końcowego RPC może spowodować zakończenie działania zebrad, dostarczając getblocktemplate LongPollId zawierający wielobajtowe znaki UTF-8. Błąd prowadzi do paniki Rust, a wersje produkcyjne używają panic=abort, co kończy cały proces.

W wersjach Zebra przed zebrad 4.4.0, zebra-chain 7.0.0 i zebra-network 6.0.0 kilka ścieżek deserializacji przychodzących danych alokowało bufory według ogólnych limitów transportu lub rozmiaru bloku, zanim zastosowano ściślejsze limity protokołu lub konsensusu. Nieuwierzytelniony lub po uzgodnieniu połączenia peer mógł wymusić na węźle prealokację i parsowanie znacznie większej ilości danych niż przewiduje protokół, w wiadomościach nagłówków, rozwiązaniach equihash w nagłówkach bloków, wektorach wydatków Sapling w transakcjach V5/V4 oraz bajtach skryptu coinbase w blokach.

ZEBRA (węzeł Zcash) przed wersjami zebrad 4.3.0 i zebra-consensus 5.0.1 ma błąd logiczny w pamięci podręcznej weryfikacji transakcji. Złośliwy górnik może wywołać podział konsensusu, dopasowując txid prawidłowej transakcji do nieprawidłowych danych autoryzacyjnych, co powoduje akceptację nieprawidłowego bloku przez podatne węzły.

ZEBRA, węzeł Zcash napisany w Rust, przed wersją zebrad 4.3.0 i zebra-chain 6.0.1 zawiera podatność w logice przetwarzania transakcji. Zdalny, nieuwierzytelniony atakujący może wysłać specjalnie spreparowaną transakcję V5, która przechodzi początkową deserializację, ale powoduje błąd podczas obliczania identyfikatora transakcji, prowadząc do paniki (awarii) węzła.