Podatności Temporal Server

Temporal Server nie wiąże tokenu paginacji historii workflow z przestrzenią nazw i workflow wskazanymi w żądaniu. Uwierzytelniony użytkownik z uprawnieniami do jednej przestrzeni nazw może użyć prawdziwego tokenu kontynuacji z innej przestrzeni nazw, aby odczytać historię workflow z tej drugiej przestrzeni, jeśli identyfikator workflow wybierze ten sam shard historii. Token jest nieuwierzytelnionym protobufem, więc można też zmienić zakres zdarzeń i wyczyścić kursor trwałości, ujawniając zdarzenia utworzone po odebraniu uprawnień.

Temporal Server zawiera moduł Worker Controller Instance (go.temporal.io/auto-scaled-workers), który rejestruje dostawcę obliczeń 'k8s' budującego klienta Kubernetes na podstawie konfiguracji z żądania wywołującego, a nie z konfiguracji operatora. Uwierzytelniony użytkownik z uprawnieniami tylko do odczytu w jednej przestrzeni nazw może wywołać operację ValidateWorkerDeploymentVersionComputeConfig, co prowadzi do wykonania dowolnego polecenia na hoście Worker Service z uprawnieniami procesu serwera. Ponieważ proces ten posiada dane uwierzytelniające do wszystkich przestrzeni nazw i materiały TLS klastra, skutki wykraczają poza przestrzeń nazw wywołującego.

Temporal Server nie wiąże wewnętrznych wywołań zwrotnych z przestrzenią nazw, która je dołączyła, co pozwala uwierzytelnionemu wywołującemu z uprawnieniami zapisu w jednej przestrzeni nazw na zmianę stanu harmonogramu Scheduler V2 w innej przestrzeni nazw. Adres wywołania zwrotnego temporal://internal jest zarezerwowany dla wywołań, które Scheduler V2 dołącza do uruchamianych przez siebie Workflows. W dotkniętych wersjach każdy uwierzytelniony wywołujący mógł dołączyć wywołanie zwrotne z tym adresem do żądania uruchomienia Workflow, adres był wyłączony z listy dozwolonych component.callbacks.allowedAddresses, a usługa History dostarczała wywołanie do komponentu wskazanego przez token, w dowolnej przestrzeni nazw, bez autoryzacji oryginalnego wywołującego. Gdy sfałszowane zakończenie pasuje do działania uruchomionego przez docelowy harmonogram, harmonogram rejestruje działanie jako ukończone, podczas gdy jego Workflow nadal działa, co może ominąć politykę nakładania się, taką jak SKIP, i przekazuje dane kontrolowane przez wywołującego do następnego zaplanowanego Workflow jako wynik ostatniego zakończenia. Sfałszowana awaria może również wstrzymać harmonogram skonfigurowany do wstrzymywania przy awarii. Sfałszowanie wymaga identyfikatora docelowej przestrzeni nazw, identyfikatora harmonogramu oraz tożsamości i czasu trwania uruchomionego działania. Nie zidentyfikowano ujawnienia ładunków Workflow ani historii. Tylko przestrzenie nazw zawierające harmonogramy Scheduler V2 mogą być celem; Scheduler V2 jest domyślnie wyłączony, a istniejące harmonogramy Scheduler V2 pozostają celami po wyłączeniu ustawień, które je tworzą.

Podatność w Temporal Server umożliwia połączonemu klastrowi modyfikację lokalnych przestrzeni nazw (namespaces) w klastrze docelowym, które nie powinny być replikowane. Odbierający klaster nie sprawdza, czy przestrzeń nazw jest globalna, i nadpisuje jej stan, opis, właściciela, retencję, ustawienia archiwizacji oraz listę klastrów, a także aktywny klaster, jeśli zadanie niesie wyższą wersję failover. Atakujący kontrolujący odpowiedzi zarejestrowanego peera może zmienić dowolną lokalną przestrzeń nazw bez poświadczeń na klastrze docelowym, np. oznaczyć ją jako Deprecated, co spowoduje błędy przy uruchamianiu nowych workflowów.

Podatność w Temporal Server umożliwia uwierzytelnionemu użytkownikowi z uprawnieniami zapisu w pojedynczej przestrzeni nazw (namespace) wykonanie dowolnego polecenia na hoście, na którym działa Worker Service. Polecenie jest wykonywane natychmiast, a proces Worker Service posiada dostęp do danych uwierzytelniających i kluczy TLS całego klastra, co eskaluje wpływ do całego klastra. Luka dotyczy wersji od 1.31.0 do 1.31.2 (przed 1.31.3) i jest obecna w domyślnych binariach i obrazach kontenerowych.

Temporal Server w wersjach 1.30.0 i nowszych decydował o tym, czy callback zakończenia Workflow jest wewnętrzny, na podstawie nagłówka HTTP dostarczonego przez wywołującego. Uwierzytelniony użytkownik z uprawnieniami zapisu w jednej przestrzeni nazw mógł dołączyć callback, którego nagłówek 'source' powodował przekierowanie żądania do wewnętrznego frontendu i wykonanie dowolnego żądania POST na administracyjnym API jako administrator systemu. W wersjach 1.25.0–1.29.7 występuje węższa wersja tej samej wady, wymagająca zgodności nagłówka z identyfikatorem klastra.

Temporal Server nie ograniczał pracy wykonywanej podczas wyszukiwania następnego czasu akcji harmonogramu. Uwierzytelniony użytkownik z uprawnieniami zapisu w namespace mógł utworzyć harmonogram łączący drobnoziarnisty interwał z kalendarzem wykluczeń odrzucającym każdy kandydat, co powodowało nadmierne zużycie CPU w komponentach Frontend i Schedule worker.

W serwerze gRPC frontendu Temporal brakowało interceptora autoryzacji w łańcuchu przetwarzania strumieniowego. Skonfigurowane ClaimMapper i Authorizer były pomijane dla endpointu AdminService/StreamWorkflowReplicationMessages, co pozwalało na dostęp bez uwierzytelnienia.

Domyślne ustawienia w otwartym serwerze Temporal przed wersją 1.20 na wszystkich platformach umożliwiają atakującemu stworzenie tokena zadania z dostępem do innej przestrzeni nazw niż ta określona w żądaniu. Wymaga to UUID przestrzeni nazw oraz informacji z historii przepływu pracy dla docelowej przestrzeni nazw.