Podatności libcurl

W bibliotece libcurl występuje problem z ponownym używaniem wcześniej utworzonych połączeń, nawet gdy zmieniono opcje związane z TLS lub SSH, które powinny zabraniać ponownego użycia. Niektóre ustawienia TLS i SSH nie były uwzględnione w sprawdzaniu zgodności konfiguracji, co ułatwiało dopasowanie.

libcurl oferuje opcję `CURLOPT_CERTINFO`, która pozwala aplikacjom na żądanie szczegółów dotyczących łańcucha certyfikatów serwera. Z powodu błędnej funkcji, złośliwy serwer może spowodować, że libcurl zbudowany z NSS utknie w nieskończonej pętli podczas próby pobrania tych informacji.

Aplikacje korzystające z libcurl mogą żądać użycia konkretnego certyfikatu klienta podczas transferu. W przypadku, gdy libcurl jest zbudowany z użyciem natywnej biblioteki TLS macOS Secure Transport, złośliwy użytkownik może podmienić certyfikat, co prowadzi do wysłania niewłaściwego certyfikatu klienta w procesie handshake TLS.

libcurl może odczytywać dane poza przydzielonym buforem pamięci podczas korzystania z FTP. Błąd w analizatorze ciągów dla nazwy katalogu może prowadzić do braku dodania bajtu NUL na końcu bufora, co skutkuje możliwością odczytu danych spoza przydzielonego obszaru pamięci.

Podatność typu use-after-free w libcurl przed wersją 7.50.1 pozwala atakującym na kontrolowanie, która konekcja jest używana, lub potencjalnie na wywołanie innych nieokreślonych skutków za pomocą nieznanych wektorów.

Funkcja ConnectionExists w lib/url.c w libcurl przed wersją 7.47.0 nieprawidłowo ponownie wykorzystuje połączenia proxy uwierzytelnione za pomocą NTLM, co może umożliwić zdalnym atakującym uwierzytelnienie jako inni użytkownicy poprzez odpowiednie żądanie.

Funkcja curl_url_get() w libcurl oferuje konwersje punycode do i z IDN. Przy konwersji nazwy o dokładnie 256 bajtach, libcurl czyta poza buforem na stosie, gdy używany jest backend IDN macidn.

Z powodu błędu w kodzie WebSocket w libcurl, złośliwy serwer może wysłać specjalnie spreparowany pakiet, który powoduje, że libcurl wpada w nieskończoną pętlę busy-loop. Aplikacja nie może uciec z tej pętli inaczej niż przez zabicie wątku/procesu. Może to być użyte do DoS.

libcurl obsługuje przypinanie klucza publicznego certyfikatu serwera dla transferów HTTPS. Z powodu pominięcia, sprawdzenie to nie jest wykonywane podczas łączenia z QUIC dla HTTP/3, gdy backend TLS to wolfSSL. Dokumentacja mówi, że opcja działa z wolfSSL, ale nie precyzuje, że nie działa dla QUIC.

Parser ASN1 w libcurl zawiera funkcję utf8asn1str() używaną do parsowania łańcucha UTF-8 ASN.1. Może on wykryć nieprawidłowe pole i zwrócić błąd. Niestety, podczas tego procesu wywołuje również free() na 4-bajtowym buforze lokalnym na stosie. Większość nowoczesnych implementacji malloc wykrywa ten błąd i natychmiast przerywa działanie.

libcurl przypadkowo pomija weryfikację certyfikatu dla połączeń QUIC, gdy łączy się z hostem podanym jako adres IP w URL. W związku z tym nie wykrywa oszustów ani ataków man-in-the-middle.

Podatność w bibliotece libcurl powoduje wyciek pamięci podczas obsługi push HTTP/2. Gdy aplikacja zezwala na push serwera, a liczba nagłówków przekracza limit 1000, libcurl przerywa push, ale nie zwalnia poprzednio zaalokowanych nagłówków.

Wada w libcurl powoduje błędne ponowne użycie połączenia HTTP ustanowionego dla danego hosta z użyciem uwierzytelniania Negotiate, gdy początkowe żądanie wykonano z pustymi poświadczeniami. Może to spowodować, że żądanie użytkownika B zostanie wysłane przez wcześniej uwierzytelnione połączenie użytkownika A.

Wada w obsłudze strumieni HTTP/2 Server Push w libcurl, gdy uchwyt nadrzędny jest ustawiony na współdzielenie połączeń z innymi uchwytami, może prowadzić do użycia po zwolnieniu (use-after-free) podczas procesu czyszczenia.

W bibliotece libcurl wykryto błąd polegający na tym, że polecenie wyczyszczenia danych uwierzytelniających proxy nie było wykonywane. Stare dane uwierzytelniające pozostawały w pamięci i były używane w kolejnych transferach, które nie powinny mieć do nich dostępu.

Podatność w bibliotece libcurl powoduje wyciek nagłówka autoryzacji proxy między żądaniami. Gdy uchwyt libcurl jest ponownie używany do sekwencyjnych transferów z konfiguracją proxy opartą na zmiennych środowiskowych, stan uwierzytelnienia proxy nie jest czyszczony między żądaniami. W rezultacie nagłówek `Proxy-Authorization:` przeznaczony dla jednego proxy może zostać wysłany do innego.

Podatność w libcurl polega na tym, że przy ponownym użyciu tego samego uchwytu do transferu do innego origin (hostB) po wcześniejszym uwierzytelnieniu Digest na hostA, libcurl błędnie przekazuje nagłówek Authorization przeznaczony dla hostA do hostB.

Podatność w bibliotece libcurl dotyczy puli połączeń, która może przechowywać połączenia z domyślnym zaufaniem do natywnych certyfikatów CA. Gdy aplikacja przełączy uchwyt na niestandardowe certyfikaty CA, stare połączenie może być nadal używane z pierwotnym zaufaniem.

W bibliotece libcurl wykryto podatność use-after-free, występującą gdy aplikacja konfiguruje drzewo zależności strumieni HTTP/2 za pomocą opcji CURLOPT_STREAM_DEPENDS lub CURLOPT_STREAM_DEPENDS_E, następnie wywołuje curl_easy_reset(), a na końcu curl_easy_cleanup(). Podczas końcowego czyszczenia libcurl próbuje uzyskać dostęp i zmodyfikować wewnętrzną strukturę, która została już zwolniona podczas resetowania.

Podatność w libcurl związana z nieprawidłowym przetwarzaniem odpowiedzi IMAP FETCH, gdy rozmiar danych wynosi zero bajtów. Funkcja deliver-data może próbować odczytać dane z bufora, który nie jest poprawnie zakończony, co prowadzi do potencjalnego odczytu pamięci poza przydzielonym obszarem.

Wielokrotne przepełnienia całkowite w funkcjach (1) curl_escape, (2) curl_easy_escape, (3) curl_unescape oraz (4) curl_easy_unescape w libcurl przed wersją 7.50.3 mogą umożliwić atakującym wywołanie nieokreślonego wpływu poprzez ciąg o długości 0xffffffff, co prowadzi do przepełnienia bufora w stercie.

Gdy w libcurl włączone jest wsparcie libpsl, libcurl nie egzekwuje granicy Public Suffix List podczas przetwarzania nagłówka Set-Cookie, gdzie atrybut Domain dokładnie odpowiada hostowi źródłowemu, który sam jest sufiksem publicznym (np. Domain=co.uk ustawione przez co.uk). Zamiast wymusić ścisły cookie host-only, libcurl zapisuje cookie z zakresem wildcard (.co.uk), co powoduje wysyłanie cookie do dowolnych subdomen w obrębie tego samego sufiksu publicznego.

W libcurl z backendem wolfSSL, gdy włączone jest buforowanie CA i funkcja CURLOPT_SSL_CTX_FUNCTION podmienia magazyn zaufania, libcurl może po wywołaniu callbacku po cichu przywrócić buforowany magazyn. Certyfikat zaufany przez buforowany magazyn, ale odrzucony przez magazyn wybrany przez callback, jest wtedy błędnie akceptowany.

W libcurl wykryto błąd polegający na błędnym ponownym wykorzystaniu istniejącego połączenia HTTPS dla danej nazwy hosta, nawet gdy używane jest inne ustawienie Native CA Store (CURLSSLOPT_NATIVE_CA) niż to, z którym połączenie zostało utworzone.

Gdy w libcurl skonfigurowano CURLOPT_PINNEDPUBLICKEY wraz z opcjami wyłączającymi standardową weryfikację peer (CURLOPT_SSL_VERIFYPEER = 0 i CURLOPT_SSL_VERIFYHOST = 0), libcurl nie egzekwuje przypinania klucza publicznego dla połączeń ustanawianych bez przedstawionego certyfikatu serwera. Obejście sprawdzenia pinningu w tych warunkach pozwala na nieuwierzytelnione połączenia, które powinny być odrzucane.

Podczas transferów przez interfejs multi w libcurl, pulowane połączenia TLS mogą przetrwać swoje oryginalne easy handles. W konfiguracjach OpenSSL 3 libcurl dołącza przydzielony kontekst biblioteki do stanu easy handle i przekazuje go do OpenSSL bez uzyskania referencji własności; przedwczesne zniszczenie easy handle zwalnia ten kontekst, podczas gdy aktywne połączenie zachowuje wiszący wskaźnik, co prowadzi do heap-use-after-free przy kolejnych operacjach I/O lub po handshake.

Wada w negocjacji SASL w libcurl dla uwierzytelniania LDAP pozwala na błędną interpretację niekompletnej sekwencji uzgadniania jako pomyślnej weryfikacji kryptograficznej. Atakujący przeprowadzający atak typu Man-in-the-Middle (MITM) może wstrzyknąć przedwczesną lub skróconą odpowiedź, która omija pełną weryfikację rówieśnika.

Podatność w libcurl umożliwia akceptację niezaufanego serwera podczas transferów SCP lub SFTP, gdy używane jest wywołanie zwrotne CURLOPT_SSH_KEYFUNCTION. Serwer może przedstawić klucz hosta innego typu niż zapisany w pliku known_hosts, a mechanizm wywołania zwrotnego nie wymusza odrzucenia niezgodności, co pozwala na udane połączenie bez ostrzeżenia.

W bibliotece libcurl nagłówek HTTP `Referer:` pozostawał ustawiony nawet po jego jawnym wyczyszczeniu. Mimo że dokumentacja wskazuje, iż przekazanie NULL do `CURLOPT_REFERER` powinno usunąć nagłówek, opcja nie czyściła stanu wewnętrznego, przez co poprzednia wartość referrera była ponownie wysyłana w kolejnych żądaniach.

W bibliotece libcurl wykryto podatność polegającą na wysyłaniu danych drugiego żądania przed zweryfikowaniem certyfikatu SSL/TLS nowego połączenia. Problem występuje, gdy używane jest buforowanie sesji SSL oraz opcja wczesnego wysyłania danych (early data), a serwer docelowy został podmieniony przez atakującego.

Wywołanie funkcji `curl_easy_pause()` wewnątrz callbacka `CURLMOPT_SOCKETFUNCTION` opartego na zdarzeniach powoduje podatność use-after-free. Libcurl próbuje zapisać flagę za pomocą wiszącego wskaźnika do struktury, tuż po zwolnieniu pamięci tego wskaźnika.

Biblioteka libcurl ponownie wykorzystywała wcześniej utworzone połączenia, nawet gdy zmieniono opcje konfiguracji mTLS związane z certyfikatami klienta, które powinny uniemożliwić ponowne użycie. Konkretnie, opcje dotyczące klucza prywatnego nie były sprawdzane przy dopasowywaniu konfiguracji.

libcurl może w niektórych okolicznościach ponownie użyć niewłaściwego połączenia, gdy proszony jest o wykonanie połączeń z autoryzacją Negotiate, nawet jeśli są one ustawione na różne 'usługi'. Z powodu błędu logicznego w kodzie, żądanie aplikacji mogło błędnie ponownie użyć istniejącego połączenia do tego samego serwera, które było uwierzytelnione przy użyciu innych usług.

Po udanym transferze przez konkretne proxy HTTP (proxyA) z uwierzytelnianiem Digest, zmiana hosta proxy na drugie (proxyB) przy ponownym użyciu tego samego uchwytu powoduje, że libcurl błędnie przekazuje nagłówek Proxy-Authorization przeznaczony dla proxyA do proxyB.

Gdy libcurl jest proszony o użycie pliku .netrc do poświadczeń oraz o podążanie za przekierowaniami HTTP, w pewnych okolicznościach mógł wyciec hasło użyte dla pierwszego hosta do hosta docelowego przekierowania.

W bibliotece libcurl, gdy dla żądania HTTP ustawiono niestandardowy nagłówek `Host:`, a następnie wykonano drugie żądanie przy użyciu tego samego uchwytu *easy handle* bez ustawionego niestandardowego nagłówka `Host:`, drugie żądanie korzystało z nieaktualnych informacji i przekazywało ciasteczka przeznaczone dla pierwszego hosta.

libcurl może w niektórych przypadkach ponownie użyć niewłaściwego połączenia dla transferów SMB(S). Z powodu błędu logicznego w kodzie operacja transferu sieciowego może błędnie użyć istniejącego połączenia SMB do tego samego serwera, ale z innym udziałem niż powinien. Może to prowadzić do pobrania niewłaściwego pliku lub przesłania pliku w niewłaściwe miejsce, przy użyciu tych samych poświadczeń i tej samej nazwy serwera.

libcurl może w pewnych okolicznościach ponownie użyć niewłaściwego połączenia przy żądaniu uwierzytelnionego transferu HTTP(S) po transferze uwierzytelnionym przez Negotiate, gdy oba używają tego samego hosta. Błąd logiczny w kodzie powoduje, że żądanie może błędnie ponownie użyć istniejącego połączenia uwierzytelnionego innymi poświadczeniami.

Istnieje podatność, w której połączenie wymagające TLS nieprawidłowo ponownie używa istniejącego niezaszyfrowanego połączenia z tej samej puli połączeń. Jeśli początkowy transfer odbywa się w postaci czystego tekstu (przez IMAP, SMTP lub POP3), kolejne żądanie do tego samego hosta omija wymóg TLS i przesyła dane niezaszyfrowane.

W bibliotece libcurl występuje błąd logiczny w mechanizmie ponownego wykorzystywania połączeń. W pewnych okolicznościach żądanie HTTP lub HTTPS z uwierzytelnianiem Negotiate może błędnie użyć istniejącego połączenia uwierzytelnionego innymi danymi logowania. W efekcie drugie żądanie z innymi poświadczeniami może zostać wysłane przez połączenie uwierzytelnione dla pierwszego użytkownika.

Podczas transferów SSH (SCP lub SFTP) z ustawionym plikiem known_hosts, libcurl mógł błędnie zaakceptować połączenia z hostami *nieobecnymi* w określonym pliku, jeśli były one rozpoznane w globalnym pliku known_hosts biblioteki libssh.

Podczas transferów TLS z ponownie używanymi uchwytami easy lub multi oraz zmianą opcji CURLSSLOPT_NO_PARTIALCHAIN, libcurl mógł przypadkowo użyć zapisanego w pamięci magazynu certyfikatów CA, dla którego opcja partial chain była odwrócona. Wbrew oczekiwaniom użytkownika, libcurl mógł znaleźć i zaakceptować łańcuch zaufania, którego w przeciwnym razie by nie zaakceptował.

Podczas wielowątkowych transferów LDAPS (LDAP przez TLS) z libcurl zmiana opcji TLS w jednym wątku nieumyślnie zmieniała je globalnie, co mogło wpływać na inne równocześnie konfigurowane transfery. Wyłączenie weryfikacji certyfikatu dla konkretnego transferu mogło przypadkowo wyłączyć tę funkcję również dla innych wątków.