Podatności Http4s

W bibliotece Http4s (moduł Ember HTTP/1.1) w wersjach przed 0.23.35 i 1.0.0-M47 nie odrzucano komunikatów zawierających jednocześnie nagłówki Transfer-Encoding i Content-Length. Umożliwia to rozbieżność w interpretacji ramek treści między pośrednikiem a serwerem Ember, co pozwala na przemyt żądań HTTP (request smuggling).

Http4s to interfejs Scala dla usług HTTP. Przed wersjami 0.23.37 i 1.0.0-M48 pętla odczytu HTTP/2 w Ember analizuje 24-bitową zadeklarowaną długość ramki, ale czeka na buforowanie całego ładunku przed porównaniem go z SETTINGS_MAX_FRAME_SIZE. Nieuwierzytelniony peer może zadeklarować ładunek bliski 16 MiB na połączeniu, gdzie Ember reklamował 16 KiB, i albo ukończyć, albo powoli go przesyłać, powodując do 1024-krotną amplifikację pamięci na połączenie przed odrzuceniem ramki przez processFrame. Współdzielona pętla H2Connection.readLoop dotyczy serwerów i klientów z http2, podczas gdy konfiguracje z wyłączonym HTTP/2 są niezależne, a poprawka odrzuca zbyt duże ramki przed buforowaniem ich ładunków. Problem naprawiono w wersjach 0.23.37 i 1.0.0-M48.

Podatność w bibliotece Http4s (interfejs Scala dla usług HTTP) przed wersjami 0.23.35 i 1.0.0-M47. Gdy Ember otrzyma ramkę HTTP/2 HEADERS lub PUSH_PROMISE bez END_HEADERS, H2Connection buforuje blok nagłówków i kolejne fragmenty CONTINUATION bez ograniczenia rozmiaru, co pozwala zdalnemu peerowi wyczerpać pamięć sterty.

Podatność w bibliotece Http4s przed wersjami 0.23.35 i 1.0.0-M47. Parser HTTP/1.1 Ember akceptuje różniące się zduplikowane nagłówki Content-Length i używa ostatniej wartości zamiast odrzucić wiadomość, co umożliwia przemyt żądań CL.CL.

Http4s to interfejs Scala dla usług HTTP. W wersjach przed 0.23.35 i 1.0.0-M47 middleware klienta CookieJar używa niezakotwiczonych sprawdzeń podciągów zamiast dopasowania domeny i ścieżki zgodnego z RFC 6265. W efekcie cookie dla example.com może zostać wysłane do kontrolowanej przez atakującego nazwy hosta, takiej jak evilexample.com.

Podatność w bibliotece Http4s przed wersjami 0.23.35 i 1.0.0-M47. WebSocket FrameTranscoder.bodyLength odrzuca rozszerzone długości ładunku powyżej Integer.MAX_VALUE, ale dopuszcza ujemne 64-bitowe długości, co pozwala zdalnemu klientowi wysłać ramkę powodującą nieskończoną pętlę dekodowania i wyczerpanie zasobów.

Http4s to interfejs Scala dla usług HTTP. W wersjach przed 0.23.35 i 1.0.0-M47 ochrona przed powtórzeniem DigestAuth zapisuje lastNc plus jeden zamiast najwyższej zaakceptowanej wartości nonce-count. Gdy legalny klient wysyła nieciągłe wartości nc z powodu równoległych lub ponawianych żądań, przechowywany licznik pozostaje poniżej zaakceptowanego maksimum, co pozwala pasywnemu obserwatorowi na wielokrotne powtórzenie przechwyconego nagłówka Authorization.

Podatność w bibliotece Http4s przed wersjami 0.23.35 i 1.0.0-M47. Ember HeaderP.parse używa testu podciągu z rozróżnianiem wielkości liter dla wartości Transfer-Encoding i dekoduje bajty nagłówka z domyślnym zestawem znaków platformy, co prowadzi do niezgodności z pośrednikami zgodnymi z RFC i umożliwia przemyt żądań TE.CL lub TE.0.

W bibliotece Http4s (serwer Ember z włączonym HTTP/2) nie jest egzekwowane ograniczenie SETTINGS_MAX_CONCURRENT_STREAMS dla strumieni tworzonych przez drugą stronę. Jedno nieuwierzytelnione połączenie może otworzyć nieograniczoną liczbę strumieni, z których każdy zachowuje swój stan, aż do wyczerpania sterty. Ten sam problem występuje w ember-client przy ramkach PUSH_PROMISE, ponieważ parametr enablePush nie jest egzekwowany. Podatność naprawiono w wersjach 0.23.35 i 1.0.0-M47.

W bibliotece Http4s okno kontroli przepływu HTTP/2 w Ember jest uzupełniane na podstawie bajtów odebranych z sieci, a nie zużytych przez aplikację, a każdy strumień przechowuje dane w nieograniczonym kanale. Złośliwy peer może wysyłać treść szybciej, niż wolna lub nieodczytująca aplikacja ją konsumuje, co prowadzi do zatrzymania ładunków w stercie na serwerze lub kliencie Ember z włączonym withHttp2. Poprawka ogranicza kanał treści strumienia H2Connection, aby konsumpcja przez aplikację wymuszała backpressure. Podatność naprawiono w wersjach 0.23.35 i 1.0.0-M47.

Http4s to interfejs Scala dla usług HTTP. W wersjach przed 0.23.35 i 1.0.0-M47 dekoder fragmentów (chunk decoder) w Ember przycina token rozmiaru fragmentu i akceptuje wiodące znaki plus lub minus zamiast wymagać co najmniej jednej cyfry szesnastkowej zakończonej wymaganym CRLF. Gdy pośrednik przekazuje dane fragmentaryczne bez ponownego kodowania i interpretuje nieprawidłowe granice fragmentów inaczej, nieuwierzytelniony atakujący może przeprowadzić przemyt żądań TE.TE, omijając kontrolę pośrednika, zatruwając pamięci podręczne lub przejmując kolejkę żądań.

Http4s to interfejs Scala dla usług HTTP. W wersjach przed 0.23.35 i 1.0.0-M47 oprogramowanie pośredniczące klienta CookieJar przechowuje atrybut Domain pliku cookie odpowiedzi bez sprawdzenia, czy pasuje on do hosta, który dostarczył plik cookie, ani bez odrzucania sufiksów publicznych. Złośliwy lub przejęty serwer kontaktowany przez ten sam CookieJar może zasadzić plik cookie dla innej domeny, a następnie jar wysyła ten plik cookie do domeny ofiary, umożliwiając utrwalenie sesji lub nadpisanie wrażliwych plików cookie.

Http4s (wersje przed 0.23.35 i 1.0.0-M47) ma podatność na wyczerpanie pamięci w serwerze Ember HTTP/2. Nieuwierzytelniony klient HTTP/2 może wysyłać ramki PING, SETTINGS lub DATA, które powodują, że serwer enqueuje odpowiedzi lub ramki WINDOW_UPDATE szybciej niż są zapisywane, co prowadzi do wyczerpania pamięci sterty.

W bibliotece Http4s middleware klienta FollowRedirect usuwa nagłówki Authorization i Cookie tylko wtedy, gdy przekierowanie zmienia autorytet, ale porównanie autorytetu pomija schemat URI. W efekcie przekierowanie z HTTPS na HTTP w obrębie tego samego autorytetu zachowuje poświadczenia i przesyła je nieszyfrowanym połączeniem.

W bibliotece Http4s metoda ResponseCookie.render zapisuje wartości name, content, domain, path i extension pochodzące z danych wejściowych bez neutralizacji średników ani znaków kontrolnych. Aplikacja tworząca ResponseCookie z niezwalidowanych danych może emitować wstrzyknięte atrybuty cookie, takie jak Domain, Path lub SameSite, rozszerzając zakres cookie lub osłabiając zabezpieczenia, a znaki kontrolne mogą umożliwić rozdzielanie nagłówków.

Http4s (wersje przed 0.23.35 i 1.0.0-M47) ma podatność na wyczerpanie pamięci w współdzielonym dekoderze WebSocket. Dekoder pozwala na nieograniczone buforowanie wiadomości, ponieważ defragmentacja gromadzi fragmenty bez limitu, a FrameTranscoder akceptuje deklarowane długości do Int.MaxValue. Zdalny klient po ukończeniu uzgadniania WebSocket może wyczerpać pamięć serwera.

Http4s (wersje przed 0.23.35 i 1.0.0-M47) ma podatność na wyczerpanie pamięci w middleware DigestAuth. Z powodu odwróconego porównania nieaktualnych nonce, middleware nie usuwa starych nonce i zatrzymuje usuwanie przy pierwszym nieaktualnym nonce. Nieuwierzytelniony atakujący może wielokrotnie wywoływać wyzwania autoryzacji, powodując wzrost mapy nonce aż do wyczerpania pamięci JVM.

W bibliotece Http4s komponenty ResourceService i WebjarService dekodują każdy segment ścieżki URL, ale odrzucają tylko segmenty dokładnie równe pustemu ciągowi, kropce lub dwóm kropkom. Żądanie zawierające zakodowany procentowo ukośnik lub ukośnik odwrotny może po dekodowaniu przekształcić akceptowany segment w przejście do katalogu nadrzędnego, umożliwiając dostęp do zasobów classpath lub WebJar poza skonfigurowaną bazą.

Http4s przed wersjami 0.23.35 i 1.0.0-M47 ma podatność na atak DoS przez HTTP/2 w backendzie Ember. Hpack wrapper nie uwzględnia w limicie rozmiaru nagłówków indeksowanych nagłówków ani narzutu na nagłówek, co pozwala na ekspansję małego bloku do dużej reprezentacji w pamięci. Wielokrotne złośliwe połączenia mogą wyczerpać pamięć procesu.