CVE-2015-8863

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.

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.

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.