Podatności ZenHive mpp

Podatność typu Time-of-check Time-of-use (TOCTOU) w ZenHive mpp umożliwia nieuwierzytelnionemu zdalnemu klientowi wykorzystanie jednej potwierdzonej płatności on-chain do wielokrotnego dostępu do płatnych zasobów. Ścieżka uwierzytelniania typu "hash" w MPP.Methods.Tempo.verify/2 chroni przed powtórzeniem za pomocą nieatomowej sekwencji sprawdź-oznacz: check_hash_unused/2 odczytuje magazyn deduplikacji, eth_getTransactionReceipt weryfikuje płatność w łańcuchu, a dopiero potem mark_hash_used/2 zapisuje znacznik. Równoczesne żądania z tym samym rozliczonym hashem płatności przechodzą przez odczyt, zanim którekolwiek zapisze, więc każde otrzymuje potwierdzenie. Magazyn posiada atomową prymitywę check_and_mark/2 używaną przez ścieżkę typu "transaction", ale ścieżka hash wywołuje zwykłe get i put nawet gdy skonfigurowany magazyn ją implementuje. Wykorzystanie wymaga skonfigurowania magazynu deduplikacji; domyślny magazyn nil jest bezstanowy i udokumentowany jako nieoferujący żadnej ochrony przed powtórzeniem. Problem dotyczy mpp od 0.2.0 przed 0.6.1.

ZenHive mpp zawiera podatność polegającą na alokacji zasobów bez limitów lub ograniczania, która pozwala nieuwierzytelnionemu zdalnemu klientowi na wyczerpanie portfela opłat poprzez równoczesne sponsorowane płatności, co prowadzi do odmowy usługi dla legalnych płatników po jego opróżnieniu. Polityka opłat egzekwuje limity tylko dla pojedynczej transakcji, a nie dla równoczesnych żądań.

ZenHive mpp zawiera podatność polegającą na obejściu uwierzytelnienia przez przechwycenie i powtórzenie, która pozwala nieuwierzytelnionej trzeciej stronie na uzyskanie płatnych zasobów poprzez powtórzenie transferu rozliczonego przez niezwiązanego płatnika. Gdy skonfigurowany jest statyczny 'memo', weryfikacja powiązania jest pomijana, a atakujący może użyć publicznego transferu jako poświadczenia.

Podatność w ZenHive mpp umożliwia nieuwierzytelnionemu zdalnemu klientowi uzyskanie płatnych zasobów poprzez ponowne przesłanie jednego rozliczonego transferu on-chain. Mechanizm weryfikacji EVM nie wiąże dowodu z wyzwaniem ani z wcześniejszym użyciem, a klucze deduplikacji są regenerowane przy każdym błędzie 402. Na trasie ze stałą ceną pojedynczy historyczny transfer spełnia wymagania nieograniczonej liczby późniejszych opłat.