Katalog podatności CVE

ApostropheCMS to open-source'owy system CMS dla Node.js. Przed wersją 4.33.0 nieuwierzytelniona trasa konwersji Rich Text CSV zapisuje przesłany plik multipart do katalogu tymczasowego systemu przed sprawdzeniem rozszerzenia i nie usuwa pliku, gdy walidacja go odrzuci. Powtarzane duże odrzucone przesłania mogą trwale zużywać pojemność dysku tymczasowego i zakłócać działanie ApostropheCMS oraz innych usług na tej samej partycji.

W sanitize-html w wersjach od 2.17.7 do 2.18.0 konfiguracja aplikacji zezwalająca na elementy animacji SVG z prefiksem przestrzeni nazw oraz odpowiednie atrybuty URL może obejść ochronę URL SMIL, ponieważ nazwy tagów z prefiksem nie pasują do sprawdzenia elementów animacji bez prefiksu. Obejście może zmienić cel linku na niebezpieczny URI po wyrenderowaniu oczyszczonego SVG, a wykonanie skryptu następuje, gdy użytkownik aktywuje dotknięty link. Domyślna konfiguracja sanitizera nie jest bezwarunkowo podatna.

Dodatek Form do ApostropheCMS przed wersją 1.5.5 przetwarza nieograniczone przesyłanie plików multipart przed walidacją formularza lub uwierzytelnieniem i nie nakłada limitów rozmiaru, liczby ani szybkości przesyłania. Powtarzane nieuwierzytelnione zgłoszenia mogą wyczerpać tymczasową przestrzeń dyskową i zakłócić obsługę formularzy lub inne usługi hosta.

W ApostropheCMS przed wersją 4.33.0 uwierzytelniony redaktor z uprawnieniami do edycji zwykłej strony zagnieżdżonej pod ograniczonym rodzicem może użyć operacji przenoszenia stron w obrębie tego samego rodzica, aby zmienić kolejność rodzeństwa bez uprawnień do tworzenia w tym rodzicu. Obejście dotyczy wyłącznie kolejności rodzeństwa, a nie dowolnej modyfikacji treści, utraty poufności ani tworzenia ograniczonego zagnieżdżenia.

W sanitize-html przed wersją 2.18.0 niedomyślna konfiguracja nonTextTags zawierająca noscript może przedwcześnie zakończyć region odrzucania, gdy htmlparser2 emituje domniemane zamknięcie elementu nadrzędnego wewnątrz noscript. Ponieważ przeglądarki ze skryptami traktują zawartość noscript jako surowy tekst, a parser nie modeluje tego trybu, treść przeznaczona do pozostania nieaktywną może przetrwać sanityzację i zostać wyrenderowana.

W ApostropheCMS przed wersją 4.33.0 viewRole nie jest stosowana do anonimowych odwiedzających, gdy deweloper udostępnia obiekty użytkowników przez publicznie renderowaną relację lub jawnie włączone publiczne API. Niewystarczająco ograniczone szablony, w tym serializacja całego powiązanego obiektu użytkownika, mogą warunkowo ujawnić pola użytkownika, ale hasła są przechowywane osobno i nie są objęte problemem.

W uploadfs od wersji 1.25.0 do 1.28.0 backend Azure ujawnia token SAS na poziomie konta w każdym publicznym adresie URL załącznika. Gdy uploadfs jest skonfigurowany z backendem Azure i sas: true, createContainer() buduje BlobServiceClient z adresu URL zawierającego pełny ciąg zapytania SAS, a klienci pochodni Azure SDK v12 dziedziczą ten ciąg.

W uploadfs przed wersją 1.28.0 ścieżki kontrolowane przez atakującego, które trafiają do lokalnego backendu, mogą zawierać segmenty katalogu nadrzędnego pozwalające wyjść poza skonfigurowany katalog uploadu i wpływać na odczyt, zapis oraz usuwanie plików w systemie plików hosta. Podatność jest wykorzystywalna w zależności od tego, czy aplikacja udostępnia odpowiednie operacje uploadfs dla niezaufanej ścieżki.

W sanitize-html 2.18.0, gdy element <iframe> nie jest dozwolony, a disallowedTagsMode ma wartość 'discard' (wartości domyślne), jego zawartość surowego tekstu jest ponownie sanityzowana przez rekurencyjne wywołanie sanitizeHtml(text, options). Rekurencja nie ma ograniczenia i rozpoczyna każde zagnieżdżone wywołanie z nowym stanem.

W module import-export przed wersją 3.7.1 oraz w rdzeniu ApostropheCMS przed wersją 4.34.0 redaktor, który może importować włączony typ treści, ale nie ma silniejszej roli publikacji, może spowodować, że pomocniki zapisu importu utworzą, zastąpią lub usuną opublikowane warianty bez normalnych uprawnień do publikacji i kontroli cyklu życia.

W module import-export ApostropheCMS przed wersją 3.7.1 endpoint API POST /api/v1/@apostrophecms/import-export/clean-export nie posiada kontroli uwierzytelnienia ani autoryzacji. Każdy klient — w tym niezalogowany anonimowy użytkownik, który uzyskał standardowe ciasteczko CSRF po odwiedzeniu strony — może bezpośrednio wywołać tę trasę i uruchomić metodę self.cleanExport(req).

W aaPanel do wersji 8.25.0 funkcja send_file w pliku BTPanel/routes/v2.py komponentu Download Endpoint pozwala na manipulację argumentem filename prowadzącą do path traversal. Atak można wykonać zdalnie, a exploit został opublikowany i może być użyty; według dostawcy zgłoszone podatności RCE i LFI wymagają uwierzytelnienia.

W ApostropheCMS przed wersją 4.34.0 zdefiniowane w projekcie pole stylu widgetu o dowolnej formie może przenieść kontrolowany przez redaktora cudzysłów do atrybutu stylu inline, ponieważ serializator opakowania nie stosuje kodowania atrybutów HTML. Cudzysłów może zakończyć atrybut stylu i wstrzyknąć wykonywalne atrybuty podczas renderowania opublikowanej treści lub szkicu wyświetlanego przez użytkownika o wyższych uprawnieniach.

ApostropheCMS w wersji przed 4.34.0 ma endpoint REST getOne dla stron, który nie stosuje ograniczeń typu viewRole ani redakcji pól viewPermission. Użytkownik na poziomie edytora, znający _id dokumentu, może odczytać pełną treść stron dostępnych tylko dla administratorów wraz z uprzywilejowanymi polami, podczas gdy endpoint getAll poprawnie egzekwuje oba ograniczenia.

Port modułów MMU Cortex-A7 waliduje bufor dostarczony przez wywołującego, tłumacząc tylko jeden adres — pierwszy bajt. Wspólny Module Manager przekazuje sprawdzenie zakresu z instancją modułu, adresem początkowym i pełnym rozmiarem w bajtach, jednak implementacja Cortex-A7 odrzuca instancję i rozmiar, pytając MMU tylko o adres początkowy. W rezultacie moduł z ochroną pamięci przechodzi każdy zakres, którego pierwszy bajt jest czytelny dla użytkownika, niezależnie od tego, jak daleko sięga reszta zakresu.

W ThreadX menedżer modułów przy usuwaniu wątku zwalniał tylko pierwszą z dwóch alokacji (blok kontrolny TX_THREAD i stos jądra TXM_MODULE_KERNEL_STACK_SIZE). Stos jądra pozostawał zajęty do zatrzymania całego modułu, więc moduł tworzący i usuwający wątki w pętli wyczerpywał współdzieloną pulę obiektów, uniemożliwiając tworzenie nowych obiektów jądra i wątków modułów w całym systemie.

Moduł ThreadX wybiera object_size podczas wywołania txm_module_object_allocate. Module Manager dodaje własny 16-bajtowy nagłówek prywatny do tego rozmiaru i żąda od puli obiektów wyniku bez sprawdzenia dodawania. Rozmiar bliski górnej granicy ULONG powoduje przepełnienie, pula zwraca blok znacznie mniejszy niż nagłówek, a manager zapisuje nagłówek poza końcem bloku, do sąsiedniego bloku puli bajtów.

Dyspozytor tworzenia puli bloków w menedżerze modułów ThreadX weryfikował tylko dwa słowa ALIGN_TYPE tablicy parametrów dostarczonej przez moduł chroniony pamięciowo, a następnie używał indeksów 0–3. Jedno z niezweryfikowanych słów jest odczytywane przez samą kontrolę zakresu (indeks 1 jako początek puli, indeks 2 jako długość), co powoduje odczyt poza granicami wykonywany przez kod walidacji przed dotarciem do usługi jądra.

Moduł ThreadX alokuje bloki kontrolne swoich obiektów jądra z puli obiektów Module Managera i może zażądać zwrotu tej pamięci przez adres za pomocą txm_module_object_deallocate. Manager zwalnia ją niezależnie od zawartości, w tym blok kontrolny wciąż używany przez jądro. Dealokacja nie jest usunięciem: obiekt pozostaje na liście utworzonych, wątek pozostaje na liście gotowych lub zawieszonych i pozostaje planowalny, a aktywny timer pozostaje na liście timerów, podczas gdy pula bajtów może przydzielić te same bajty kolejnej alokacji.

W menedżerze modułów ThreadX wyszukiwanie obiektów walidowało tylko jeden bajt nazwy wyszukiwania modułu chronionego pamięciowo, a następnie przeglądało ją w trybie uprzywilejowanym z podniesionym licznikiem wywłaszczania. Funkcja txm_module_object_pointer_get_extended otrzymuje długość, ale jej nie używa do ograniczenia bufora, a przestarzała txm_module_object_pointer_get przekazuje maksymalną wartość UINT, usuwając ograniczenie.