Podatności MongoDB

W MongoDB 2.6, przy użyciu użytkowników w stylu 2.4, zdalni atakujący mogą spowodować odmowę usługi poprzez wykorzystanie reprezentacji bazy danych w pamięci podczas próby uwierzytelnienia w nieistniejącej bazie danych.

MongoDB w wersjach 3.4.x przed 3.4.10 oraz 3.5.x-development ma domyślnie wyłączoną konfigurację networkMessageCompressors, która, gdy jest włączona, może być wykorzystana przez złośliwego atakującego do odmowy usługi lub modyfikacji pamięci.

Podczas planowania zapytań w MongoDB, przy odczytywaniu wzorca sortowania w surowej formie BSONObj, w niektórych miejscach nie obsłużono jawnie przypadku wyrażenia meta. Może to prowadzić do nieprawidłowych transformacji i błędu invariant failure.

Brak sprawdzenia zakresu w akcesorach elementów BSON CodeWScope umożliwia atakującemu wywołanie odczytu poza stertą poprzez spreparowany potok agregacji. Podatność może być wykorzystana przez uwierzytelnionego użytkownika poprzez wygenerowanie zniekształconych danych BSONColumn zawierających element CodeWScope, omijając walidację BSON na poziomie sieci. Podczas dekompresji sfałszowanego elementu, niesprawdzona wartość rozmiaru jest używana w arytmetyce wskaźników, powodując awarię serwera lub ujawnienie sąsiednich danych sterty.

Uwierzytelniony użytkownik może spowodować zakończenie procesu mongod przez system operacyjny pod presją pamięci, wykonując określoną operację konwersji typu danych w frameworku agregacji MongoDB. Wymaga to dostępu do zapisu bazy danych i możliwości uruchamiania zapytań agregacji.

Uwierzytelniony użytkownik może spowodować zakończenie procesu mongod przez system operacyjny pod presją pamięci poprzez etapy agregacji $rankFusion i $scoreFusion. Problem leży w ścieżce obsługi błędów serwera i wymaga możliwości uruchamiania zapytań agregacji.

MongoDB jest podatny na atak DoS polegający na nadmiernym zużyciu CPU. Niezautoryzowany klient może wysłać specyficzną kombinację parametrów do polecenia hello w trybie exhaust, powodując pętlę odpowiedzi omijającą normalne ograniczniki.

Uwierzytelniony użytkownik z uprawnieniami tylko do odczytu może spowodować nieprawidłowe zakończenie procesu mongod poprzez wysłanie spreparowanego polecenia agregacji. Prowadzi to do odmowy usługi dla wszystkich podłączonych klientów do czasu restartu procesu. Problem wynika z niespójności w wyborze wewnętrznego silnika.

Gdy tryb compute jest włączony na samodzielnej instancji mongod, niewystarczająca walidacja zewnętrznych danych BSON podczas przetwarzania potoku agregacji może prowadzić do uszkodzenia pamięci, potencjalnie powodując zakończenie procesu lub inne niepożądane zachowanie. Ta konfiguracja jest niestandardowa i wymaga jawnego włączenia przy starcie.

Uwierzytelniony użytkownik z dostępem do odczytu może spowodować zakończenie procesu mongod przez system operacyjny pod presją pamięci poprzez pewne wyrażenia agregacji wykonujące JavaScript po stronie serwera. Problem dotyczy nieprawidłowego zarządzania pamięcią podczas przetwarzania dokumentów.

Serwer MongoDB inicjujący wychodzące połączenie TLS może zakończyć się nieprawidłowo podczas przetwarzania nieprawidłowej odpowiedzi OCSP od zdalnego peera podczas uzgadniania TLS. Walidacja OCSP stapling jest domyślnie włączona dla wychodzących połączeń TLS.

Uwierzytelniony użytkownik może spowodować nadmierne zużycie CPU lub braki pamięci na serwerze MongoDB poprzez wysłanie spreparowanego zapytania Queryable Encryption find z niezweryfikowanym polem sterującym wewnętrzną pętlą obliczeniową. Wyczerpanie zasobów obniża dostępność dla innych operacji.

Gdy protokół PROXY v2 jest używany na gnieździe domeny Unix, role pochodzące z certyfikatów klienta X.509 mogą nie być weryfikowane względem listy dozwolonych tlsCATrusts. Może to skutkować nieprzewidzianym przypisaniem ról po uwierzytelnieniu MONGODB-X509.

Nieprawidłowe przetwarzanie obiektów DBPointer podczas serializacji BSON w silniku JavaScript po stronie serwera MongoDB może spowodować, że dane z pamięci procesu zostaną dołączone do odpowiedzi dla klienta. Dotyczy to wdrożeń używających JavaScript po stronie serwera.

Użytkownik z uprawnieniami tylko do odczytu może stworzyć potok agregacji z operatorem $linearFill i określonym typem wyrażenia sortBy, powodując nieprawidłowe zakończenie procesu mongod (odmowa usługi).

Operacje zapytań wykorzystujące głęboko zagnieżdżone konstrukcje $jsonSchema mogą powodować nadmierne zużycie procesora w podatnych instalacjach MongoDB, prowadząc do wyczerpania zasobów. Proces związany z obciążeniem CPU nie może zostać przerwany za pomocą standardowych narzędzi administracyjnych.

Uwierzytelniony użytkownik z uprawnieniami odczytu/zapisu może spowodować zakończenie procesu mongod z powodu braku pamięci, wysyłając spreparowane polecenie agregacji. Biblioteka libmongocrypt nieprawidłowo waliduje wartości dostarczone w ładunku, co może prowadzić do nadmiernej alokacji pamięci.

Uwierzytelniony użytkownik z uprawnieniami do zapisu w kolekcji z włączonym szyfrowaniem zapytań może modyfikować wewnętrzne pola metadanych szyfrowania, które powinny być kontrolowane przez serwer, wysyłając spreparowane polecenia zapisu przez router mongos w klastrze shardowanym. Może to prowadzić do uszkodzenia poprawności szyfrowanych zapytań.

Uwierzytelniony użytkownik może wyświetlić metadane sesji innych użytkowników za pomocą etapu agregacji $listSessions. Informacje te są normalnie ograniczone do użytkowników z uprawnieniami administracyjnymi na poziomie klastra i obejmują identyfikatory aktywnych sesji, powiązane nazwy użytkowników oraz znaczniki czasu aktywności.

Uwierzytelniony użytkownik z ograniczonymi uprawnieniami odczytu może uzyskać dostęp do dokumentów z kolekcji, do których nie ma autoryzacji. Wynika to z niespójności w ocenie etapu agregacji $graphLookup podczas autoryzacji i wykonania. Podatność dotyczy kolekcji przywoływanych w istniejących definicjach widoków potoku.

Uwierzytelniony użytkownik z niskimi uprawnieniami może wykonywać nieautoryzowane odczyty i zapisy danych chronionych przez kontrolę dostępu na poziomie zapytań opartą na rolach. Problem wynika z niewystarczającej walidacji parametrów poleceń dostarczanych przez klienta i dotyczy poleceń find, update, delete oraz aggregate w konfiguracjach innych niż apiStrict.

Podatność w MongoDB, w której uwierzytelniony użytkownik z podstawowymi uprawnieniami do zapisu może spowodować nieprawidłowe zakończenie procesu mongod poprzez wysłanie spreparowanego polecenia transakcji z niekompletnym zestawem wymaganych pól. Prowadzi to do błędu wewnętrznego asercji i odmowy usługi.

W serwerze MongoDB integracja Atlas Search pozwala uwierzytelnionemu użytkownikowi ominąć kontrolę dostępu na użytkownika. W topologiach shardowanych etapy agregacji $search i $searchMeta mogą być bezpośrednio dostarczane przez klienta z powodu niewystarczającej walidacji wejścia.

Używając wyrażeń generujących duże tablice, można stworzyć zapytanie, które tworzy bardzo duże obiekty pośrednie w pamięci, powodując awarię serwera z błędem braku pamięci (OOM).

Wyrażenie agregacji `$_internalIndexKey` może być użyte przez dowolnego uwierzytelnionego użytkownika do awarii serwera MongoDB (mongod). Wyrażenie nie obsługuje poprawnie specyfikacji złożonych indeksów wieloznacznych, co wyzwala wewnętrzną kontrolę spójności i powoduje zatrzymanie procesu serwera. Użytkownik musi mieć możliwość uruchomienia potoku agregacji.

Etap potoku agregacji $_internalApplyOplogUpdate może być wykorzystany do wykonania dyfuzyjnego dokumentu zawierającego nieprawidłową dyfuzję binarną, co prowadzi do odczytu poza zakresem pamięci lub awarii serwera. Każdy uwierzytelniony użytkownik z dostępem do polecenia aggregate może uruchomić tę operację.

Autoryzowany użytkownik może spowodować awarię serwera, uruchamiając zapytanie z indeksem 2dsphere na polu przechowującym GeoJSON GeometryCollection zawierający Polygon z CRS o ścisłym nawijaniu. Ochrona przed takimi wielokątami nie sprawdza elementów GeometryCollection, co prowadzi do wyłuskania wskaźnika null.

Parametr ldapQueryPassword ustawiony za pomocą polecenia runtime setParameter jest zapisywany w pliku mongod.log w postaci jawnego tekstu.

Uwierzytelniony użytkownik MongoDB może spowodować awarię serwera lub zwrócenie nieprawidłowych wyników poprzez tworzenie dokumentów zakłócających przetwarzanie metadanych wewnętrznych podczas wykonywania zapytań. Wynika to z niewystarczającego oddzielenia pól dokumentów użytkownika od metadanych wewnętrznych.

Podczas uruchamiania potoku agregacji z wewnętrznym etapem $exchange skonfigurowanym z partycjonowaniem zakresu kluczy i dostarczaniem z zachowaniem kolejności, jeśli pojedynczy zakres kluczy wyprodukuje wystarczająco dużo dokumentów, aby wypełnić bufor wymiany, serwer trafia na ścieżkę kodu, gdzie wykrywany jest pełny bufor na konsumenta, ale wewnętrzny „wysoki znak wodny” dla tego zakresu kluczy nie jest aktualizowany zgodnie z przeznaczeniem.

W MongoDB, etap $_internalConvertBucketIndexStats używa PauseExecution jako sygnału do pominięcia dokumentu, ale PauseExecution jest przeznaczony tylko do koordynacji podpotoków w $facet. Gdy ten etap znajduje się przed $facet, TeeBuffer otrzymuje nieoczekiwany sygnał i narusza asercję, powodując awarię mongod.

Dodanie opcji fromRouter:true i runtimeConstants.userRoles może spowodować awarię serwera MongoDB podczas agregacji.

Użycie $changestreams i $_requestReshardingResumeToken z opcją exchange powoduje naruszenie niezmiennika, co prowadzi do awarii serwera. Nie są wymagane specjalne uprawnienia, ale użytkownik musi być zalogowany.

Błąd w przetwarzaniu analizy zapytań w etapie agregacji $vectorSearch dla Queryable Encryption (QE) lub Client-Side Field Level Encryption (CSFLE) powoduje, że wartości literałowe dla zaszyfrowanych pól w wyrażeniach filtru etapu $vectorSearch są wysyłane do serwera jako zwykły tekst zamiast szyfrogramu.

Serwer MongoDB może rejestrować parametry uwierzytelniania, w tym poświadczenia, w logach serwera podczas uwierzytelniania SASL. Gdy włączone jest rejestrowanie metryk kondycji połączenia, pełne parametry uwierzytelniania są zapisywane w logu bez maskowania.