Podatności libcurl

Luka w libcurl pozwala atakującemu wstawiać dowolne ciasteczka do działającego programu przy spełnieniu określonych warunków. Gdy uchwyt easy z włączonymi ciasteczkami jest duplikowany przez curl_easy_duphandle, a źródłowy uchwyt nie odczytał ciasteczek z pliku, sklonowany uchwyt zapisuje nazwę pliku jako "none", co może spowodować nieumyślne wczytanie ciasteczek z pliku o nazwie "none" w bieżącym katalogu.

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.

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.

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.

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.

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.

Gdy operacja wieloznacznego LIST przez FTP kończy się niepowodzeniem, libcurl pomija ścieżkę przywracania przeznaczoną dla udanych listowań, pozostawiając callback zapisu ustawiony na wewnętrzny parser listowania, a dane callbacku zapisu wskazujące bezpośrednio na uchwyt easy. Ponowne użycie tego uchwytu powoduje natychmiastową awarię, a sklonowanie go przez curl_easy_duphandle() kopiuje uszkodzony stan; zwolnienie oryginału i transfer na klonie powoduje use-after-free, a zmiana tylko CURLOPT_WRITEDATA prowadzi do type confusion.

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.

Funkcja GTime2str() w parserze ASN.1 biblioteki libcurl, używana do parsowania pola Generalized Time, może przy niepoprawnym składniowo polu użyć wartości -1 jako długości części ułamkowej czasu. Prowadzi to do wywołania strlen() na wskaźniku do bufora sterty, który nie jest zakończony znakiem null. Luka najprawdopodobniej powoduje awarię, ale może również spowodować zwrócenie zawartości sterty do aplikacji, gdy używane jest CURLINFO_CERTINFO.

Gdy aplikacja poinformuje libcurl, że chce zezwolić na HTTP/2 server push, a liczba odebranych nagłówków dla push przekroczy maksymalny dozwolony limit (1000), libcurl przerywa server push. Przy przerwaniu libcurl nie zwalnia wszystkich wcześniej przydzielonych nagłówków, co powoduje wyciek pamięci. Błąd ten występuje w sposób cichy i dlatego jest trudny do wykrycia przez aplikację.

Podczas wysyłania danych do serwera MQTT, libcurl <= 7.73.0 i 7.78.0 mógł w niektórych okolicznościach błędnie zachować wskaźnik do już zwolnionego obszaru pamięci, a następnie użyć go ponownie w kolejnym wywołaniu do wysyłania danych, a także zwolnić go *ponownie*.

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 przechowuje wcześniej używane połączenia w puli w celu ponownego wykorzystania. Błąd w logice dopasowywania konfiguracji powodował, że nie brano pod uwagę opcji 'issuercert', a porównywanie ścieżek odbywało się bez rozróżniania wielkości liter, co mogło prowadzić do ponownego użycia niewłaściwych połączeń.

Z powodu użycia zwisającego wskaźnika, libcurl w wersjach od 7.29.0 do 7.71.1 może użyć niewłaściwego połączenia podczas wysyłania danych.

Przepełnienie liczby całkowitej w API URL curl prowadzi do przepełnienia bufora w libcurl w wersjach od 7.62.0 do 7.64.1 włącznie.

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.

libcurl może przypadkowo zwrócić URL dla opcji CURLINFO_EFFECTIVE_URL funkcji curl_easy_getinfo() zawierający dane uwierzytelniające, mimo że ani URL przekazany do libcurl, ani URL przekierowania ich nie zawierały.

Głęboko zagnieżdżona struktura MIME multipart zbudowana przez publiczne API powoduje przepełnienie stosu w libcurl podczas normalnych operacji sprzątania. Nadmierna głębokość rekurencji w curl_mime_free prowadzi do nieograniczonej alokacji ramek stosu podczas przechodzenia struktury, co ostatecznie powoduje awarię procesu hosta.

Maszyna stanów TFTP w libcurl nie weryfikuje przejść stanów względem żądanego kierunku transferu, akceptując odpowiedzi otwierające serwera zarówno dla odczytu, jak i zapisu zamiennie. Złośliwy serwer TFTP może odpowiedzieć na żądanie pobrania w sposób wymuszający tryb transmisji, powodując że libcurl odczyta i wyśle dane ze wskaźnika CURLOPT_READDATA uchwytu, w tym dane pozostałe z wcześniejszych operacji, takich jak żądanie HTTP POST na ponownie użytym uchwycie.

Poprzez trwałe pominięcie końcowej linii odpowiedzi kontrolnej złośliwy serwer FTP, IMAP, POP3 lub SMTP może wykorzystać libcurl i całkowicie obejść skonfigurowany mechanizm limitu czasu transferu, blokując w nieskończoność wszystkie równoległe transfery powiązane z tym samym multi-handle.

Gdy libcurl używa libssh2 z plikiem known_hosts w formacie hashowanym, niepowiązany początkowy wpis może spowodować, że walidacja klucza hosta zgłosi niezgodność klucza jako brakujący klucz do callbacku CURLOPT_SSH_KEYFUNCTION.

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.