„Read-only” to jedna z tych etykiet, które potrafią uspokoić cały proces bezpieczeństwa. Konto ma tylko odczyt, nie może zmieniać konfiguracji, nie jest administratorem — czyli ryzyko powinno być ograniczone. CVE-2026-50152 w Ceph pokazuje, dlaczego taka intuicja bywa bardzo niebezpieczna.
Podatność dotyczy Monitor subscription handlera. Użytkownik CephX posiadający zaledwie mon allow r może wysłać odpowiednio przygotowany MMonSubscribe i odczytać cały Monitor config-key store. A tam mogą znajdować się OSD LUKS passphrases, dashboard secrets, gateway credentials, inne sekrety klastra — a w klastrach zarządzanych przez cephadm również SSH private key używany do administracji wszystkimi hostami Cepha:
To nie jest zwykły information disclosure. To collapse granicy zaufania.
Co dokładnie mówi upstream?
Oficjalna dokumentacja Cepha opisuje CVE-2026-50152 jako improper authorization flaw w Monitor subscription handler.
cephadm upstream zaleca również rotację klucza SSH.To wskazuje, że sama aktualizacja pakietu nie wyczerpuje remediation.
Dlaczego mon allow r brzmi niewinnie?
Capability mon allow r intuicyjnie oznacza możliwość odczytu danych z monitorów. Dla wielu security reviewerów taki credential wygląda na ograniczony. Problem polega na tym, co dokładnie da się odczytać. Jeżeli read-only API zwraca klucz administracyjny, hasło szyfrujące dyski albo gateway credentials, to realna capability nie jest już read cluster metadata, tylko read credentials that grant higher authority. To fundamentalne rozróżnienie.
Declared privilege vs effective privilege
W VM często analizujemy required privilege. Ale tu ważniejsze jest effective privilege after secret disclosure. Na wejściu: CephX read-only. Po exploicie: cephadm SSH private key. A jeśli ten klucz pozwala administracyjnie wejść na hosty klastra — root-level host access. Atakujący nie eskaluje przez klasyczny local privilege escalation, tylko przez credential transitivity.
Credential transitivity
To bardzo ważne pojęcie dla nowoczesnego VM. Credential A może być niskiego poziomu, ale jeśli A pozwala odczytać B, a B daje dużo większe uprawnienia, prawdziwy attack graph wygląda tak: Credential A → read secret B → assume privilege B. W Cephie: CephX mon allow r → Monitor config-key → cephadm SSH key → host root. Ten sam wzorzec spotykamy przy Kubernetes Secret disclosure, CI/CD credential leakage, cloud metadata service, Vault token exposure, backup secrets i service-account token theft.
Dlaczego CVSS nie oddaje intuicyjnie całości?
Red Hat ocenia problem jako Important. Atak nie jest unauthenticated — wymaga dostępu do cluster network, ważnej tożsamości CephX i capability mon allow r. To realne preconditions. Ale po ich spełnieniu pojedynczy crafted message deterministycznie zwraca cały config-key store:
To dobry przykład, dlaczego jedna etykieta severity nie opisuje całej decyzji operacyjnej.
Czy każdy klaster ma ten sam impact?
Nie — i to jedna z najważniejszych części tego case'u. W klastrze z cephadm config-key store może zawierać cephadm SSH private key, więc atakujący może potencjalnie przejść do host-level root. Klaster bez cephadm nie musi mieć tego klucza, ale nadal może przechowywać LUKS passphrases, dashboard secrets, RGW credentials i inne tajemnice. Czyli: same CVE, different secret inventory, different blast radius. Priorytet może zależeć od wersji Cepha, obecności cephadm, ekspozycji cluster network, liczby tożsamości CephX z mon allow r, secret inventory i host criticality.
Co powinien sprawdzić Vulnerability Engineer?
- Gdzie są klastry Ceph (production, DR, lab, OpenStack backend, Kubernetes storage, standalone).
- Czy wersje są starsze niż 19.2.6 / 20.2.4 w odpowiednich liniach.
- Czy klaster używa
cephadm— kluczowy faktor blast radius. - Kto ma
mon allow r— nie tylko ludzie, ale i service accounts, monitoring, automation, integration users. - Skąd można połączyć się do monitorów — czy cluster network jest dobrze segmentowana.
- Co znajduje się w config-key store — trudniejsze pytanie, ale ważne dla realnego impact assessment.
Remediation to nie tylko patch
Ceph zaleca upgrade. Ale jeśli config-key store mógł zostać odczytany, remediation powinno objąć także sekrety. Dla cephadm: rotate SSH key. Dla pozostałych wartości: assess and rotate relevant secrets. Zasada brzmi: patch usuwa możliwość ponownego wycieku, ale nie unieważnia sekretów, które mogły już wyciec — dokładnie ten sam problem co po kompromitacji tokenu, backupu czy credential store.
Patch vs compromise remediation
Warto rozdzielić vulnerability remediation (upgrade Ceph) od credential remediation (rotate cephadm SSH key, rotate exposed secrets, review access). Jeśli system VM zamknie finding tylko dlatego, że wersja została podniesiona, może pozostawić aktywny credential zdobyty wcześniej przez atakującego. Nie ma podstaw, by bezwarunkowo twierdzić, że każdy klaster został skompromitowany — ale jeśli występowała podatna wersja, ktoś posiadał odpowiedni CephX key i istnieją oznaki podejrzanej aktywności, należy rozważyć compromise assessment i rotację. Upstream sam silnie zaleca operatorom cephadm rotację klucza — to już nie jest zwykłe „upgrade recommended”.
Read-only credential nie jest zawsze low-risk
Najważniejsza lekcja jest szersza niż Ceph. Jeżeli read-only credential może odczytać secrets, tokens, signing keys, passwords albo kubeconfigs, jego realny poziom zaufania jest wysoki. Dojrzała organizacja powinna klasyfikować dane według pytania „what can be derived from the read access?”, a nie tylko „can this identity write?”. Systemy secret-bearing — Ceph Monitor, Vault, Kubernetes API, CI/CD, cloud secret stores — powinny mieć wyższy asset criticality, bo podatność confidentiality bardzo szybko zamienia się w integrity compromise, root, lateral movement lub data destruction. Klasyczna triada CIA nie zawsze jest niezależna.
Wniosek
CVE-2026-50152 pokazuje, że „read-only” jest tylko nazwą operacji — nie opisuje skutków danych, które można odczytać. Jeśli read-only CephX → reads admin SSH key, realny attack path kończy się daleko poza granicą sugerowaną przez nazwę permission. Dlatego VE powinien pytać: czy ten credential pozwala odczytać credential o wyższym poziomie zaufania? Jeśli tak, mamy nie information disclosure, lecz credential-to-root escalation chain.
Powiązane na blogu
- Ograniczone ssm:SendCommand, a plik jako root — effective privilege po przejściu przez cały chain
- Dwa CVE, jeden łańcuch — zbieranie credentiali i ich przenośność
Źródła
- Ceph Security — CVE-2026-50152 (Monitor config-key store readable by any CephX key) — docs.ceph.com
- Red Hat — CVE-2026-50152 — access.redhat.com
- Ceph — cephadm SSH configuration — docs.ceph.com
Nota redakcyjna: stan informacji 29 sierpnia 2026, 22:30 CEST. Poprawki dostępne w Ceph Squid 19.2.6 i Tentacle 20.2.4. Upstream zaleca natychmiastowy upgrade oraz — szczególnie operatorom klastrów cephadm — rotację klucza SSH. Impact zależy od konfiguracji klastra i sekretów przechowywanych w Monitor config-key store.