Katalog podatności CVE

YesWiki w wersji przed 4.6.7 zawiera obejście zakresu pustego filtra w API usuwania trójek, które pozwala każdemu uwierzytelnionemu użytkownikowi usuwać lub fałszować dowolne trójki semantyczne niezależnie od własności. Atakujący może wysłać pusty filtr do punktu końcowego usuwania trójek, aby usunąć trójkę członkostwa w grupie admins, opróżniając grupę administratorów i powodując blokadę autoryzacji w całej witrynie.

YesWiki w wersjach przed 4.6.7 zawiera nieuwierzytelnioną podatność server-side request forgery, która pozwala zdalnym atakującym zmusić serwer do pobierania dowolnych adresów URL poprzez dostarczenie akcji syndykacji przez parametr content handlera render. Atakujący mogą celować w wewnętrzne hosty i porty, odczytywać pobraną treść kanału w renderowanej stronie oraz powodować pobieranie załączników kanału do katalogu plików.

YesWiki w wersjach przed 4.6.7 zawiera nieuwierzytelnioną podatność server-side request forgery, która pozwala zdalnym atakującym zmusić serwer do pobierania dowolnych hostów i portów poprzez parametr url akcji {{valeur}}. Atakujący mogą przesłać akcję przez parametr content handlera handlers/page/render.php, aby sondować wewnętrzne usługi HTTP i odczytywać treść odpowiedzi pasującą do znaczników fiche.

YesWiki w wersjach przed 4.6.7 zawiera ślepą podatność server-side request forgery, która pozwala nieuwierzytelnionym atakującym wykonywać dowolne żądania po stronie serwera poprzez parametr idtypeannonce w /api/entries/bazarlist. Ponieważ isValidURL() zawsze zwraca true, atakujący mogą podać wewnętrzne adresy URL pobierane przez curl w loadURLContent() w celu sondowania sieci wewnętrznych i docierania do wewnętrznych usług lub punktów końcowych metadanych.

YesWiki w wersjach przed 4.6.7 zawiera podatność enumeracji użytkowników w LostPasswordAction.php, która pozwala nieuwierzytelnionym atakującym potwierdzać zarejestrowane adresy e-mail poprzez różniące się odpowiedzi. Atakujący mogą przesyłać e-maile do strony odzyskiwania MotDePassePerdu bez ograniczeń szybkości, aby identyfikować ważne konta do ukierunkowanego phishingu lub password-sprayingu.

YesWiki w wersjach przed 4.6.7 zawiera podatność braku autoryzacji w akcjach listpagestag i includepages narzędzia tags, które wyliczają strony bez stosowania filtrowania read-ACL. Nieuwierzytelnieni lub nieuprzywilejowani atakujący mogą osadzić te akcje z wybranym tagiem lub nazwą strony, aby ujawnić nazwy i tytuły pochodzące z treści stron z ograniczeniami ACL.

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 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 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 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.

Metoda RPC getblock w zebra-rpc przed wersją 11.0.0, używana przez węzeł Zebra Zcash Foundation, powoduje panikę przy verbosity 2 dla bloku bocznego łańcucha, ponieważ wartownik -1 potwierdzeń jest konwertowany na u32 z użyciem .expect(), co przerywa proces. Zdalni nieuwierzytelnieni atakujący, bezpośrednio lub przez lightwalletd, mogą powtarzać to wywołanie, utrzymując węzeł w pętli awarii.

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ść 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 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.

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.