Podatności Temporal Server

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.