Podatności hawtio-operator

W hawtio-operator podczas wdrażania Hawtio w trybie klastrowym tworzony jest OAuthClient o zasięgu klastrowym z automatycznym zatwierdzaniem (GrantMethod: auto) i bez klucza klienta. URI przekierowań pochodzą z trasy utworzonej przez operatora, której nazwa hosta jest kontrolowana przez dzierżawcę. Złośliwy dzierżawca może zarejestrować dowolną nazwę hosta jako prawidłowy cel przekierowania OAuth i uzyskać tokeny dostępu OpenShift dowolnego użytkownika klastra, który odwiedzi spreparowany URL autoryzacyjny.

W hawtio-operator ClusterRole przyznaje uprawnienia secrets: [create, get, list, update, watch] we wszystkich przestrzeniach nazw. Mimo że operator używa cache z selektorem etykiet jako optymalizacji pamięci, token ServiceAccount autoryzuje dostęp do odczytu wszystkich sekretów w klastrze. Operator omija cache poprzez bezpośrednie wywołania API. Kompromitacja poda operatora umożliwiłaby odczyt wszystkich sekretów w klastrze, w tym tokenów bootstrap, poświadczeń chmurowych i sekretów innych operatorów.

W hawtio-operator znaleziono błąd: operator odczytuje prywatny klucz podpisujący Service CA z przestrzeni nazw openshift-service-ca i używa go do tworzenia certyfikatów klienckich z CN dostarczonym przez autora zasobu Hawtio. Operator dostarcza ClusterRole, która agreguje uprawnienia do zasobów Hawtio do ról edit i admin, więc każdy użytkownik z prawem edycji w dowolnej przestrzeni nazw może uzyskać certyfikat podpisany przez Service CA z dowolnym podmiotem. Certyfikat może być użyty do podszywania się pod dowolną tożsamość usługi w klastrze dla elementów ufających Service CA, w tym agentów Jolokia.