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.

Jeśli tryb logowania jest ustawiony na DEBUG lub używany jest nieprawidłowy ciąg połączenia MongoDB, logi aplikacji mogą gromadzić wrażliwe informacje (jeśli są używane), takie jak hasła i klucze dostępu AWS. Może to prowadzić do nieautoryzowanego dostępu do chronionych zasobów.

Nieograniczone zużycie zasobów w procesie routera klastra sharded MongoDB. Klient z dostępem sieciowym do portu routera, bez uwierzytelnienia, może wysyłać parametry monitorowania połączeń, które powodują nadmierne zużycie CPU bez ograniczania szybkości, co pogarsza lub uniemożliwia działanie usługi dla legalnych klientów. Nie wymaga uwierzytelnienia ani interakcji użytkownika. Wpływa tylko na dostępność, nie na poufność ani integralność danych.

Podatność w kodzie generowania błędów walidacji JSON Schema w MongoDB pozwala uwierzytelnionemu użytkownikowi z uprawnieniami readWrite na awarię serwera mongod. Gdy dokument BSON zawierający tablicę z nieprawidłową nazwą pola numerycznego nie spełnia ograniczenia typu items w $jsonSchema, ścieżka generowania błędu wykonuje niebezpieczną konwersję numeryczną na nazwie pola kontrolowanej przez użytkownika bez odpowiedniej obsługi wyjątków, co powoduje nieprzechwycony wyjątek i zakończenie procesu serwera. Jest to możliwe, ponieważ walidacja BSON w protokole sieciowym nie egzekwuje, że nazwy pól elementów tablicy są prawidłowymi, mieszczącymi się w zakresie indeksami numerycznymi.

Odkryto problem bezpieczeństwa w MongoDB, gdzie uwierzytelniony użytkownik z uprawnieniami readWrite może spowodować awarię procesu serwera mongod. Poprzez podanie niestandardowej opcji konfiguracji WiredTiger z niezgodną wartością podczas tworzenia kolekcji, użytkownik może wywołać pomyłkę typu w warstwie silnika składowania. Gdy dokumenty są następnie odczytywane z nieprawidłowo skonfigurowanej kolekcji, wynikająca z tego niezgodność w oczekiwanym formacie danych prowadzi do uszkodzonej interpretacji pamięci i awarii serwera. Spreparowana konfiguracja kolekcji utrzymuje się po ponownych uruchomieniach, wymagając ręcznej interwencji operatora w celu naprawy.

Błąd wyścigu w parsowaniu zapytań indeksu tekstowego serwera MongoDB może powodować odczyt po zwolnieniu (use-after-free) na stercie podczas obsługi ścieżek ponawiania operacji upsert. W pewnych współbieżnych operacjach na cyklu życia indeksu, surowy wskaźnik do wewnętrznych metadanych indeksu tekstowego może być wyłuskiwany po zwolnieniu podstawowych struktur, co prowadzi do awarii serwera. Uwierzytelniony użytkownik z uprawnieniami readWrite może wywołać ten stan poprzez określone współbieżne operacje wyszukiwania tekstowego i zarządzania indeksem, co powoduje denial of service dla wszystkich podłączonych klientów.

Problem bezpieczeństwa w generowaniu kluczy indeksu 2dsphere w MongoDB może powodować awarię serwera z powodu wyłuskania pustego wskaźnika. Gdy specjalnie spreparowany dokument GeoJSON jest wstawiany do kolekcji z indeksem 2dsphere, niespójność w parsowaniu geometrii może pozostawić wewnętrzny obiekt w nieprawidłowym, częściowo zainicjalizowanym stanie. Podczas późniejszego generowania klucza indeksu, dostęp do tego nieprawidłowo zainicjalizowanego obiektu powoduje wyłuskanie pustego wskaźnika, co kończy proces mongod. Uwierzytelniony użytkownik z prawem zapisu może to wykorzystać do spowodowania denial of service.

Problem bezpieczeństwa istnieje w parserze JSON Pointer serwera MongoDB używanym podczas przetwarzania filtrów zapytań $jsonSchema. Gdy polecenie find zawiera specjalnie spreparowane pole filtra $jsonSchema, parser przetwarza dane wejściowe bez egzekwowania odpowiednich limitów liczby iteracji lub całkowitego rozmiaru alokacji, co powoduje znaczną amplifikację pamięci. Pod współbieżnym obciążeniem żądaniami, skumulowane zużycie pamięci może wyczerpać dostępną pamięć sterty, powodując, że mechanizm obsługi braku pamięci serwera kończy proces mongod i odmawia usługi wszystkim podłączonym klientom.

Wyrażenie $regexFindAll może być użyte przez uwierzytelnionego użytkownika, który może uruchamiać etapy potoku agregacji, do spowodowania awarii serwera MongoDB (mongod). W określonych warunkach dopasowanie regex może rozpocząć się w środku znaku składającego się z wielu jednostek kodowych, co wywołuje asercję podczas wykonywania zapytania.

Nieautoryzowany użytkownik z dostępem do zapisu w magazynie kluczy może spowodować, że autoryzowany klient wyśle dowolne uwierzytelnione żądania do Google Cloud KMS pod tożsamością autoryzowanego użytkownika, eskalując dostęp na poziomie bazy danych do kontroli kluczy w chmurze i omijając szyfrowanie po stronie klienta.

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.