Katalog podatności CVE

NetBox w wersjach od 2.9.5 do 4.7.0 zawiera lukę server-side template injection, która pozwala użytkownikowi o niskich uprawnieniach z uprawnieniem "Can add custom links" na kradzież ciasteczek sesyjnych i tokenów API innych użytkowników poprzez udostępnienie surowego obiektu Django HttpRequest w kontekście szablonu Jinja2. Atakujący może osadzić w szablonie niestandardowego linku odwołanie do request.COOKIES['sessionid'] lub tokenu API w adresie URL obrazka, omijając sanitizer clean_html i automatycznie eksfiltrując dane uwierzytelniające ofiary. Umożliwia to pełne przejęcie konta.

Dell Command | Configure (DCC) w wersjach przed 5.2.3.35 zawiera podatność polegającą na użyciu wbudowanego klucza kryptograficznego. Nieuwierzytelniony atakujący z dostępem lokalnym może potencjalnie wykorzystać tę podatność, prowadząc do ujawnienia informacji.

W GitHub Enterprise Server występuje podatność braku autoryzacji, która pozwala współpracownikowi repozytorium z prawem zapisu usunąć bieżącą gałąź domyślną przez GraphQL API i uczynić gałąź kontrolowaną przez atakującego nową domyślną. W repozytoriach wymagających przeglądu pull requestów, ale nieograniczających usuwania gałęzi, omija to wymóg przeglądu i powoduje, że nowe klony oraz zapytania API używają treści kontrolowanych przez atakującego.

Nieprawidłowa autoryzacja w mechanizmie SiteIsolation w przeglądarce Google Chrome przed wersją 155.0.8059.39. Zdalny atakujący mógł wykonać dowolny kod poprzez spreparowaną stronę HTML. (Waga: wysoka)

W funkcji is_pd_allowed w pliku gem_msg.c brakuje sprawdzenia uprawnień, co umożliwia obejście zabezpieczeń. Może to prowadzić do lokalnego ujawnienia informacji, ale wymaga uprawnień wykonania w systemie. Do wykorzystania nie jest potrzebna interakcja użytkownika.

W sssd znaleziono błąd, który pozwala lokalnemu użytkownikowi wywołać Denial of Service (DoS) poprzez wyczerpanie dostępnych deskryptorów plików usługi odpowiadającej. Otwierając i utrzymując wiele połączeń z gniazdem odpowiedzi oraz kolejkowanie nowych prób połączeń, atakujący może wywołać nieograniczoną pętlę ponawiania, co prowadzi do wysokiego użycia CPU i zatrzymania usługi.

W WordPressie występuje podatność polegająca na wstawianiu wrażliwych informacji do wysyłanych danych, co umożliwia odzyskanie osadzonych wrażliwych danych. Problem dotyczy wielu wersji WordPressa od 6.6 do 7.1.2.

W bibliotece ImageSharp w wersjach od 3.0.0 do 4.1.1 dekodowanie paskowego pliku TIFF z kompresją CCITT Group 3 lub Modified Huffman może przekazywać rozszerzone przez atakującego ciągi do BitWriterUtils.WriteBits bez uprzedniego sprawdzenia szerokości wiersza. T4TiffCompression.WritePixelRun może gromadzić zbyt duże ciągi kodów makeup, a ModifiedHuffmanTiffCompression.Decompress sprawdza szerokość dopiero po zapisie. Niekontrolowane zapisy mogą przepełnić bufor paska, uszkodzić pamięć sterty i zakończyć proces. Podatność została naprawiona w wersji 4.1.1.

W bibliotece ImageSharp od wersji 2.0.0 do 4.1.2 funkcja ExifReader.ReadValues64 ufa 64-bitowej liczbie wpisów IFD w formacie BigTIFF i iteruje raz na każdy zadeklarowany wpis. Gdy pozostało mniej niż 20 bajtów, funkcja ReadValue64 zwraca bez przesuwania strumienia lub kończenia pętli, co pozwala małemu uszkodzonemu plikowi BigTIFF utrzymać wątek dekodera przez czas kontrolowany przez atakującego. Problem naprawiono w wersji 4.1.2.

W bibliotece ImageSharp w wersjach od 2.1.0 do 4.1.2 koder TIFF CCITT Group 4 alokuje bufor o rozmiarze Width razy rowsPerStrip, mimo że T6BitCompressor.CompressStrip może wygenerować dane wiersza i dwa 12-bitowe kody końca bloku faksu przekraczające tę pojemność. TiffCcittCompressor.WriteCode wykonuje niezaznaczone zapisy, a przepływ dekodowania i ponownego kodowania może odziedziczyć TiffCompression.CcittGroup4Fax i metadane jednobitowe z danych wejściowych atakującego. Powstałe zapisy poza zakresem mogą uszkodzić pamięć i zakończyć proces. Podatność została naprawiona w wersji 4.1.2.

W bibliotece ImageSharp od wersji 1.0.0-beta0001 do 4.1.2 parsowanie CLUT w profilach ICC oblicza rozmiary alokacji na podstawie zadeklarowanych przez atakującego wymiarów kanałów i siatki, zanim potwierdzi, że profil zawiera te wartości. Funkcja IccDataReader.ReadClutF32 może żądać dużej tablicy float, a wcześniejsze ścieżki parsowania IccProfile.Entries mogą przydzielić dużą reprezentację z krótkiego profilu. W wersji 4 automatyczna konwersja obrazu dociera do parsera, gdy DecoderOptions.ColorProfileHandling jest ustawione na Convert; domyślny tryb Preserve unika tej ścieżki. Problem naprawiono w wersji 4.1.2.

W bibliotece ImageSharp w wersjach od 2.0.0 do 4.1.2 dekodowanie dostarczonego przez atakującego 32-bitowego pliku TIFF zmiennoprzecinkowego jako Image<HalfVector4> i zastosowanie HistogramEqualization może wygenerować nieskończoną lub poza zakresem luminancję w ColorNumerics.GetBT709Luminance. GrayscaleLevelsRowOperation.Invoke używa wynikowej wartości jako niezaznaczonego przesunięcia histogramu, powodując niebezpieczny dostęp poza zakresem i zakończenie procesu. Adaptive Histogram Equalization i AutoLevel nie są objęte tym raportem. Podatność została naprawiona w wersji 4.1.2.

W bibliotece ImageSharp w wersjach od 4.0.0 do 4.1.2 konwersja ICC LUT16 akceptuje więcej niż cztery kanały wyjściowe, mimo że ClutCalculator.Calculate i LutEntryCalculator.CalculateLut przechowują wartości pośrednie i wyjściowe w Vector4. Gdy DecoderOptions.ColorProfileHandling jest ustawione na Convert, złośliwy osadzony profil może spowodować zapis jednego float na zadeklarowany kanał poza czteroelementowym miejscem docelowym. Może to uszkodzić pamięć i zakończyć proces; domyślny tryb Preserve nie uruchamia konwersji ICC. Podatność została naprawiona w wersji 4.1.2.

W bibliotece ImageSharp od wersji 4.0.0 do 4.1.2 funkcja ExrBaseDecompressor.UndoZipCompression akceptuje niepusty wynik dekompresji ZIP lub ZIPS, który jest krótszy niż wymagany rozmiar bloku EXR. ZipExrCompression.Decompress rekonstruuje zwrócony prefiks, podczas gdy ExrDecoderCore przetwarza pełny oczekiwany blok z bufora uzyskanego przez Configuration.Default, co pozwala na pojawienie się bajtów z wcześniej zakończonej operacji ImageSharp w zdekodowanych pikselach. Aplikacje, które udostępniają piksele lub dane wyjściowe z późniejszego dekodowania EXR, mogą ujawnić dane obrazu lokalnego procesu. Problem naprawiono w wersji 4.1.2.

W bibliotece ImageSharp w wersjach od 2.0.0 do 4.1.2 koder TIFF CCITT Group 3 alokuje zbyt mały bufor skompresowanych danych dla wąskich obrazów 1-bitowych. TiffCcittCompressor.Initialize nie rezerwuje wystarczającej ilości miejsca na dane wiersza i kody końca linii T4, a T4BitCompressor.CompressStrip wykonuje niezaznaczone zapisy, gdy TiffCompression.CcittGroup3Fax jest wybrane bezpośrednio lub odziedziczone z metadanych dekodowanego pliku TIFF. Przepływ kodowania lub dekodowania i ponownego kodowania kontrolowany przez atakującego może zapisać poza logicznym zakresem wyjściowym, uszkodzić pamięć procesu i zakończyć proces. Podatność została naprawiona w wersji 4.1.2.

W Quasar Framework od wersji 1.0.0 do 3.3.0 pakiet @quasar/app-vite rekurencyjnie usuwał rozwiązany katalog build.distDir przed budowaniem, bez odrzucania katalogu głównego projektu, katalogu domowego użytkownika, korzeni systemu plików lub zewnętrznych katalogów rozwiązanych przez dowiązania symboliczne. Niebezpieczna, zaufana konfiguracja może usunąć dane zapisywalne przez użytkownika budującego przed rozpoczęciem kompilacji. Domyślnie żadne dane kontrolowane przez atakującego nie docierają do build.distDir, więc wykorzystanie wymaga skompromitowanej lub mniej zaufanej automatyzacji lub błędnej konfiguracji. Problem naprawiono w wersji 3.3.0.

Quasar Framework przed wersją 3.3.0 w kilku ścieżkach renderowania SSR i SSG @quasar/app-vite interpoluje ssrContext.nonce bezpośrednio do atrybutów HTML w cudzysłowach. Aplikacja, która wyznacza lub nadpisuje tę wartość danymi kontrolowanymi przez atakującego, może pozwolić na zamknięcie atrybutu nonce cudzysłowem i wstrzyknięcie dodatkowych atrybutów lub znaczników do generowanego HTML. Nonce generowane kryptograficznie w base64 lub base64url nie są podatne, ponieważ nie zawierają delimiterów atrybutów HTML. Podatność została naprawiona w wersji 3.3.0.

Quasar Framework przed wersjami @quasar/render-ssr-error 2.2.4 i @quasar/app-vite 3.3.0: funkcja renderSSRError() w utils/render-ssr-error/src/index.js używała danych diagnostycznych z utils/render-ssr-error/src/env.js do serializacji process.env, nagłówków żądań i ciasteczek do strony HTTP zwracanej przez serve.devError(), podczas gdy serwer deweloperski domyślnie nasłuchiwał na wszystkich interfejsach. Każdy klient sieciowy, który osiągnie błąd renderowania SSR lub SSG przez tę ścieżkę błędów, może uzyskać sekrety środowiska powłoki. Renderer escapował tylko jedną dokładną małą literę zamykającego tagu script, więc warianty wielkości liter i prawidłowe warianty delimiterów mogły zakończyć element script i wstrzyknąć znaczniki. Podatność została naprawiona w @quasar/render-ssr-error 2.2.4 i @quasar/app-vite 3.3.0.

Quasar Framework przed wersjami @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4 i @quasar/app-vite 3.3.0 przechowuje połączony klucz prywatny i certyfikat PEM w pamięci podręcznej bez ustawienia odpowiednich uprawnień dostępu (tylko właściciel). Inny lokalny użytkownik może skopiować klucz i podszyć się pod deweloperski punkt końcowy TLS w środowisku ufającym certyfikatowi. Wygenerowany certyfikat ma również niepotrzebnie szerokie zastosowania klucza i zawiera adres IPv6 loopback jako DNS SAN.

Quasar Framework przed wersją 2.23.3 przekazuje nieograniczony nagłówek User-Agent do funkcji getMatch() w Platform.parseSSR(), co w połączeniu z wyrażeniami regularnymi powoduje super-liniowe cofanie (backtracking) i blokowanie pętli zdarzeń Node.js. Złośliwy nieuwierzytelniony żądanie może opóźnić wszystkie inne żądania SSR. Problem dotyczy tylko trybu SSR; inne cele (SPA, PWA itp.) nie są podatne.