Katalog podatności CVE

IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 mogą pozwolić lokalnemu atakującemu na podniesienie uprawnień z powodu nieprawidłowego zarządzania uprawnieniami.

IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 mogą pozwolić zdalnemu atakującemu na spowodowanie odmowy usługi z powodu niekontrolowanego zużycia zasobów.

IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 mogą pozwolić zdalnemu atakującemu na dostęp do systemów plików eksportowanych przez NFS z powodu nieprawidłowego uwierzytelniania.

IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 mogą pozwolić zdalnemu atakującemu na uzyskanie uprawnień root z powodu nieprawidłowego uwierzytelniania.

IBM PowerVM Hypervisor w wersjach FW1120.00, FW1110.00 do FW1110.30 oraz FW1060.00 do FW1060.80 zawiera podatność związaną z nieprawidłową kontrolą ciągów formatujących. Lokalny atakujący może wykorzystać tę wadę do uzyskania poufnych informacji lub spowodowania odmowy usługi.

IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 NIM mogą pozwolić zdalnemu atakującemu na uzyskanie nieautoryzowanego dostępu do systemów AIX z powodu nieprawidłowej walidacji certyfikatów TLS.

IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 NIM mogą pozwolić zdalnemu uwierzytelnionemu atakującemu na wykonanie dowolnych poleceń z powodu nieprawidłowej neutralizacji specjalnych elementów w poleceniu OS.

IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 NIM mogą pozwolić zdalnemu atakującemu na ominięcie zabezpieczeń z powodu ujawnienia kluczy prywatnych pośredniego urzędu certyfikacji w publicznie dostępnym pliku aktualizacji.

Usługa rejestracji nimesis w IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 umożliwia zdalnemu atakującemu nadpisanie plików z powodu podatności na przechodzenie po ścieżkach (path traversal).

Proces serwera NIM w IBM AIX 7.2, 7.3 oraz IBM PowerVM VIOS 4.1 ulega awarii podczas rejestracji klienta z powodu przepełnienia bufora.

Pakiet stigmem (stigmem-node) w wersji 0.9.0a1 zawiera niezgodność w obsłudze znaczników czasu podczas walidacji tokenów peer w federacji, co powoduje błędne traktowanie ważnych tokenów jako wygasłych. Problem wpływa na dostępność i niezawodność uwierzytelnionych przepływów federacyjnych. Poprawiono w wersji 0.9.0a2.

stigmem-node zawiera niebezpieczną domyślną konfigurację, która pozwala na przesyłanie ruchu federacyjnego bez ochrony mTLS, gdy włączone są punkty końcowe inne niż loopback. Operatorzy, którzy celowo wyłączyli mTLS i jednocześnie wiążą federację z adresami innymi niż loopback, narażają ruch federacyjny na przechwycenie w postaci jawnego tekstu i ataki typu man-in-the-middle.

Wersje stigmem przed 0.9.0a2 pozwalają na nieuwierzytelniony dostęp, gdy uwierzytelnianie jest wyłączone na wdrożeniach innych niż loopback. Atakujący mogą wykonywać operacje odczytu, zapisu i federacji z anonimową tożsamością, gdy węzły są wystawione poza lokalne środowiska deweloperskie.

stigmem-node 0.9.0a1 akceptuje materiał klucza federacyjnego podczas rejestracji peera bez osobnego kroku zatwierdzenia odcisku palca przez administratora poza pasmem. Na węzłach, które akceptują rejestrację peera federacyjnego przez sieć, gdzie początkowa rejestracja może być przechwycona lub przekierowana, atakujący może zarejestrować złośliwego peera i uzyskać dostęp do ruchu federacyjnego lub go modyfikować. Naprawiono w 0.9.0a2, który wprowadza przepływ zatwierdzania oczekującego wymagający weryfikacji odcisku palca administratora przed zaakceptowaniem tokenów peera.

stigmem-node 0.9.0a1 umożliwia wyłączenie wymuszania podpisów wtyczek za pomocą pojedynczego flagi konfiguracyjnej, bez drugiego wyraźnego potwierdzenia. Jeśli to ustawienie zostanie przeniesione do środowiska, gdzie katalogi wtyczek są zapisywalne przez mniej zaufanych użytkowników, niepodpisany (potencjalnie złośliwy) kod wtyczki może zostać załadowany i wykonany, co prowadzi do arbitralnego wykonania kodu. Poprawiono w 0.9.0a2.

stigmem-node 0.9.0a1 interpoluje identyfikatory schematów backendu Postgres do zapytań SQL bez odpowiedniego cytowania. W dotkniętej ścieżce kodu wartość schematu jest kontrolowana przez operatora, ale niebezpieczny wzorzec może umożliwić wstrzyknięcie SQL, jeśli nazwa schematu pochodzi z danych dzierżawcy, żądania lub użytkownika. Poprawiono w 0.9.0a2.

Stigmem przed wersją 0.9.0a11 nie waliduje parametru delivery_address podczas tworzenia subskrypcji webhook, co pozwala uwierzytelnionym użytkownikom na określenie wewnętrznych adresów loopback i prywatnych sieci. Atakujący mogą wywołać zdarzenia zmiany faktów, aby serwer Stigmem wysyłał żądania HTTP POST do wewnętrznych usług, umożliwiając ataki SSRF na localhost i prywatne endpointy.

stigmem przed wersją 0.9.0a12 zawiera podatność na złamanie autoryzacji na poziomie obiektu w punkcie końcowym decay sweep, która pozwala uwierzytelnionym atakującym z poświadczeniami zapisu dla jednego dzierżawcy na wykonywanie operacji decay wpływających na wszystkich dzierżawców. Atakujący mogą wysyłać żądania POST z ttl_seconds=0, aby wygaszać fakty we wszystkich dzierżawcach, lub użyć dry_run do uzyskania informacji o faktach i ich istnieniu między dzierżawcami.

stigmem-node przed wersją 0.9.0a12 zawiera podatność na złamanie autoryzacji na poziomie obiektu (BOLA) w punktach końcowych przeglądu kwarantanny. W środowiskach wielodostępnych z opcjonalną wtyczką stigmem-plugin-multi-tenant, zapytania list/count oraz _get_quarantined_fact w routes/quarantine.py nie zawierały predykatu tenant_id, a wyszukiwanie garden nie było ograniczone do dzierżawcy, co pozwalało administratorowi dzierżawcy z uprawnieniami zapisu na listowanie, odczyt oraz akceptowanie lub odrzucanie faktów z kwarantanny należących do innych dzierżawców przez /v1/quarantine. Domyślne wdrożenia jedno-dzierżawcze nie są dotknięte.

stigmem-node przed wersją 0.9.0a12 zawiera podatność na złamanie autoryzacji na poziomie obiektu (BOLA) w mechanizmie tombstone RTBF (prawo do bycia zapomnianym). issue_tombstone domyślnie ustawiał dzierżawcę na "default" zamiast dzierżawcy wywołującego, co pozwalało na zapis rekordów usunięcia do niewłaściwego dzierżawcy, a ścieżka tłumienia odczytu (_get_tombstone_filter i cache zakresu tombstone) nie zawierała predykatu tenant_id, więc tłumienie tombstone było stosowane bez uwzględnienia dzierżawcy w zapytaniach o fakty i odczytach pochodzenia. W rezultacie usunięcie jednego dzierżawcy mogło być przypisane do innego, a tłumienie tombstone mogło ukrywać fakty innych dzierżawców lub nie ukrywać faktów we właściwym dzierżawcy, podważając izolację danych i gwarancje RTBF. Podatność jest wykorzystywana tylko w środowiskach wielodostępnych z opcjonalną wtyczką stigmem-plugin-multi-tenant; wdrożenia jedno-dzierżawcze nie są dotknięte. Poprawiono w 0.9.0a12.