Podatności jq

Funkcja jv_dump_term w jq 1.5 umożliwia zdalnym atakującym spowodowanie odmowy usługi poprzez przygotowany plik JSON, co prowadzi do zużycia stosu i awarii aplikacji. Problem został naprawiony w jq 1.6_rc1-r0.

Funkcja decNumberCopy w pliku decNumber.c w jq do wersji 1.7.1 nieprawidłowo traktuje wartość NaN jako liczbową, co prowadzi do przepełnienia bufora na stosie i zapisu poza zakresem. Problem można wykorzystać na przykład przez użycie opcji --slurp z operacją odejmowania, taką jak filtr .-. przy odpowiednio spreparowanym wejściu.

Błąd off-by-one w funkcji tokenadd w pliku jv_parse.c w jq umożliwia zdalnym atakującym spowodowanie awarii (denial of service) poprzez długi, zakodowany w JSON numer, co prowadzi do przepełnienia bufora w pamięci heap.

W jq w wersji 1.8.1 i wcześniejszych ścieżki importu akceptują osadzone bajty NUL na poziomie języka jq, ale podczas wyszukiwania modułów i plików danych są one przetwarzane przez operacje na łańcuchach C. Powstaje rozbieżność między logicznym łańcuchem importu a rzeczywistą ścieżką otwieraną na dysku.

W jq w wersji 1.8.1 i wcześniejszych funkcja decNumberFromString przy literale liczbowym o długości INT_MAX-1 (2147483646) cyfr powoduje przepełnienie makra D2U() w arytmetyce ze znakiem. Zawinięta wartość ujemna omija sprawdzenie rozmiaru alokacji sterty i prowadzi do zapisu około 1,4 GiB danych kontrolowanych przez atakującego poza bufor stosu.

jq to procesor JSON wiersza poleceń. W wersji 1.8.1 i wcześniejszych stos danych maszyny wirtualnej bajtkodu śledzi rozmiar alokacji w typie int ze znakiem; gdy stos przekroczy ok. 1 GiB, arytmetyka podwojenia ulega przepełnieniu, a wynik trafia do realloc i memmove z offsetami kontrolowanymi przez atakującego.

W jq w wersji 1.8.1 i wcześniejszych programy jq najwyższego poziomu ładowane z pliku przez opcję -f są obcinane na pierwszym osadzonym bajcie NUL. Spreparowany plik filtra może zostać skompilowany i wykonany tylko jako prefiks przed bajtem NUL, co pozostawia niespójność między prefiksem a pełnym buforem na ścieżce kompilacji.

jq przed commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 używało MurmurHash3 z zakodowanym na stałe, publicznie widocznym ziarnem (0x432A9843) dla wszystkich operacji na tablicach mieszających obiektów JSON. Umożliwiło to atakującemu wstępne obliczenie kolizji kluczy offline i dostarczenie spreparowanego obiektu JSON (~100 KB), w którym wszystkie klucze trafiają do tego samego koszyka, powodując degradację wyszukiwania z O(1) do O(n) i wyczerpanie CPU.

jq to procesor JSON wiersza poleceń. Commity przed 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b zawierają podatność, w której parsowanie danych wejściowych CLI pozwala na obejście walidacji poprzez osadzone bajty NUL. Podczas czytania JSON z plików lub standardowego wejścia jq używa strlen() do określenia długości bufora zamiast rzeczywistej liczby bajtów z fgets(), co powoduje obcięcie danych wejściowych na pierwszym bajcie NUL i parsowanie tylko poprzedzającego prefiksu. Umożliwia to atakującemu stworzenie danych wejściowych z nieszkodliwym prefiksem JSON przed bajtem NUL, po którym następują złośliwe dane końcowe, gdzie jq waliduje tylko prefiks jako poprawny JSON, jednocześnie po cichu odrzucając sufiks. Przepływy pracy polegające na jq do walidacji niezaufanego JSON przed przekazaniem go do dalszych odbiorców są podatne na ataki różnic parserów, ponieważ ci odbiorcy mogą przetwarzać pełne dane wejściowe, w tym złośliwe końcowe bajty. Problem został załatany commitem 6374ae0bcdfe33a18eb0ae6db28493b1f34a0a5b.

W bibliotece libjq (część narzędzia jq) w funkcji jv_parse_sized() występuje podatność na odczyt poza zakresem bufora. Podczas przetwarzania błędnego JSON-a w buforze niezakończonym znakiem NUL, funkcja formatująca błąd używa %s, które czyta dane aż do napotkania NUL-a, zamiast ograniczyć się do długości podanej przez wywołującego.

jq przed wersją 1.8.2 zawiera podatność w wbudowanej funkcji _strindices, która przekazuje argumenty do jv_string_indexes() bez weryfikacji, czy są one stringami. Funkcja jv_string_indexes() polega wyłącznie na asercjach, które są usuwane w wersjach release kompilowanych z -DNDEBUG. Atakujący może spowodować awarię jq, np. przez _strindices(0), a także uzyskać kontrolowany dereferencję wskaźnika i ograniczony odczyt pamięci.

jq to procesor JSON wiersza poleceń. W wersjach 1.8.1 i starszych funkcje jv_setpath(), jv_getpath() i delpaths_sorted() w src/jv_aux.c używają nieograniczonej rekurencji, której głębokość zależy od długości tablicy ścieżki dostarczonej przez wywołującego, bez limitu głębokości. Atakujący może dostarczyć dokument JSON z płaską tablicą ~65 000 liczb całkowitych (~200 KB), który po użyciu jako argument ścieżki przez zaufany filtr jq wyczerpuje stos wywołań C i powoduje awarię procesu (SIGSEGV).

jq to procesor JSON wiersza poleceń. W wersjach do 1.8.1 występuje luka przepełnienia liczb całkowitych w funkcjach jvp_string_append() i jvp_string_copy_replace_bad, gdzie łączenie ciągów o łącznej długości przekraczającej 2^31 bajtów powoduje przepełnienie 32-bitowej liczby całkowitej bez znaku w obliczeniu rozmiaru bufora, co skutkuje drastycznie zaniżonym buforem sterty. Kolejne operacje kopiowania pamięci zapisują pełne dane ciągu do tego zaniżonego bufora, powodując przepełnienie bufora sterty (CWE-190 prowadzące do CWE-122). Każdy system oceniający niezaufane zapytania jq jest narażony, ponieważ atakujący może zawiesić proces lub potencjalnie uzyskać dalszą eksploatację poprzez uszkodzenie sterty, tworząc zapytania generujące ekstremalnie duże ciągi. Przyczyną jest brak sprawdzania ograniczeń rozmiaru ciągów, w przeciwieństwie do tablic i obiektów, które mają już limity rozmiaru. Problem został rozwiązany w commicie e47e56d226519635768e6aab2f38f0ab037c09e5.