Podatności curl

Gdy curl ma używać HSTS, czas wygaśnięcia dla subdomeny może nadpisać wpis w pamięci podręcznej domeny nadrzędnej, powodując wcześniejsze lub późniejsze wygaśnięcie niż zamierzono. Dotyczy to aplikacji używających HSTS i adresów URL z niebezpiecznym schematem HTTP://.

Podczas przetwarzania przekierowania HTTP do adresu URL zawierającego komponent userinfo (username:password) curl może błędnie zachować i ponownie przesłać stan uwierzytelniania HTTP Negotiate oryginalnego hosta. W efekcie złośliwy serwer może wymusić na curl wysłanie świeżo wygenerowanego biletu Kerberos do niezaufanego hosta trzeciego, omijając ograniczenia zakresu domeny normalnie wymuszane przez brak opcji --location-trusted.

Przy kompilacji z wolfSSL curl może pomyślnie zweryfikować hash przypiętego klucza publicznego względem klucza, którego peer TLS nie posiada. Podczas uzgadniania TLS wolfSSL weryfikuje połączenie, ale późniejsze ponowne parsowanie tego samego certyfikatu przez curl — oszukane przez zmanipulowane pole długości ważności — wyodrębnia i dopasowuje inny osadzony klucz, niepoprawnie autoryzując przypięty klucz publiczny.

Przy użyciu poświadczeń użytkownika w tle żądanie HTTP skierowane do jednego originu może zostać wysłane przez połączenie wcześniej uwierzytelnione przez Negotiate dla innego originu. W rezultacie zamierzone poświadczenia żądania pozostają nieużyte.

Złośliwy serwer proxy HTTP może nakłonić libcurl do wysłania poświadczeń originu (hasła Basic lub biletu Negotiate/Kerberos) do samego proxy. Osiąga to, odpowiadając na żądanie tunelu CONNECT kodem 401 z nagłówkiem WWW-Authenticate zamiast oczekiwanego 407 Proxy-Authenticate.

Przy użyciu użytkownika w tle w pierwszym transferze z uwierzytelnianiem Negotiate i żądaniem podążania za przekierowaniami curl może przekazać szczegóły poświadczeń do niepowiązanego drugiego originu. Może to nastąpić, gdy serwer zażąda przekierowania do innego originu.

Transfer ftp:// skonfigurowany z CURLUSESSL_NONE może ponownie użyć połączenia kontrolnego FTP z puli, które wcześniej zostało uaktualnione przez STARTTLS i uwierzytelnione certyfikatem klienta. Drugi uchwyt nie wykonuje nowego uzgadniania TLS ani nowego logowania FTP, więc serwer nadal autoryzuje go pod tożsamością certyfikatu pierwszego uchwytu.

Gdy curl używa pliku .netrc do znalezienia poświadczeń i jednocześnie podano URL z nazwą użytkownika (bez hasła), curl może błędnie pobrać i użyć hasła innego użytkownika z .netrc dla tego hosta, jeśli nie ma dopasowania dla podanego użytkownika.

W bibliotece curl wykryto podwójne zwolnienie pamięci (double-free) w mechanizmie uwierzytelniania SASL. Błąd powoduje, że kontekst GSASL jest czyszczony dwukrotnie bez wyzerowania wskaźnika, co prowadzi do wywołania funkcji free() na tym samym obszarze pamięci.

Błąd w logice parsowania ciasteczek w curl pozwala złośliwemu serwerowi HTTP ustawiać "super cookies", które omijają sprawdzanie Public Suffix List, umożliwiając wstrzykiwanie ciasteczek do niepowiązanych domen trzecich.

Podatność CVE-2023-38545 dotyczy przepełnienia bufora w pamięci sterty podczas handshake'u proxy SOCKS5 w narzędziu curl. Problem występuje, gdy curl przekazuje zbyt długą nazwę hosta do proxy, co prowadzi do nieprawidłowego kopiowania danych.

W curl w wersjach przed v7.88.0 występuje podatność polegająca na przesyłaniu poufnych informacji w postaci czystego tekstu, która może powodować awarię funkcji HSTS przy sekwencyjnym żądaniu wielu adresów URL. Mechanizm HSTS jest ignorowany przy kolejnych transferach w tej samej linii poleceń, ponieważ stan nie jest prawidłowo przenoszony.

W curl przed 7.84.0 podczas transferów FTP zabezpieczonych przez krb5, błędnie obsługiwane są błędy weryfikacji wiadomości. Ta wada umożliwia atak typu Man-In-The-Middle pozostający niezauważonym i pozwala na wstrzyknięcie danych do klienta.

Gdy curl < 7.84.0 zapisuje ciasteczka, alt-svc i dane HSTS do plików lokalnych, wykonuje operację atomowo, finalizując ją przez zmianę nazwy z tymczasowej nazwy na docelową nazwę pliku. W tej operacji zmiany nazwy może przypadkowo *rozszerzyć* uprawnienia dla pliku docelowego, pozostawiając zaktualizowany plik dostępnym dla większej liczby użytkowników niż zamierzano.

curl w wersjach poniżej 7.84.0 obsługuje łańcuchowe algorytmy kompresji HTTP, co oznacza, że odpowiedź serwera może być skompresowana wielokrotnie, potencjalnie różnymi algorytmami. Liczba akceptowanych ogniw w łańcuchu dekompresji była nieograniczona, co pozwalało złośliwemu serwerowi wstawić praktycznie nieograniczoną liczbę kroków kompresji.

Złośliwy serwer może wysłać nadmierną liczbę nagłówków `Set-Cookie:` w odpowiedzi HTTP do curl, a curl w wersjach poniżej 7.84.0 przechowuje je wszystkie. Wystarczająco duża liczba dużych plików cookie powoduje, że kolejne żądania HTTP stają się większe niż wewnętrzny próg curl (1048576 bajtów), co skutkuje zwróceniem błędu.

Podatność w curl 7.83.0 związana z niewystarczającą ochroną danych uwierzytelniających. Przy przekierowaniach HTTP na ten sam host, ale inny port, może dojść do wycieku nagłówków uwierzytelniania lub danych cookie.

curl obsługuje opcję linii poleceń -t, znaną jako CURLOPT_TELNETOPTIONS w libcurl. Ta rzadko używana opcja służy do wysyłania par zmienna=treść do serwerów TELNET. Z powodu błędu w parserze opcji do wysyłania zmiennych NEW_ENV, libcurl może przekazać niezainicjalizowane dane z bufora na stosie do serwera, potencjalnie ujawniając wrażliwe informacje wewnętrzne serwerowi przy użyciu protokołu przesyłanego jawnym tekstem. Stało się tak, ponieważ curl nie wywoływał i nie używał poprawnie funkcji sscanf() podczas parsowania ciągu dostarczonego przez aplikację.

Gdy curl jest instruowany do pobierania treści za pomocą funkcji metalink, zawartość jest weryfikowana względem hasha podanego w pliku XML metalink. Plik metalink wskazuje klientowi, jak uzyskać tę samą treść z różnych adresów URL, potencjalnie hostowanych przez różne serwery. Jeśli jeden z serwerów hostujących treść został naruszony, a zawartość pliku na tym serwerze została zastąpiona zmodyfikowanym ładunkiem, curl powinien to wykryć, gdy hash pliku nie zgadza się po zakończonym pobieraniu. Powinien usunąć zawartość i spróbować pobrać ją z innego adresu URL. Tak się nie dzieje; zamiast tego taka niezgodność hasha jest tylko wspomniana w tekście, a potencjalnie złośliwa zawartość pozostaje w pliku na dysku.

curl w wersjach 7.75.0 do 7.76.1 cierpi na podatność use-after-free, która powoduje użycie już zwolnionej pamięci, gdy przychodzi ticket sesji TLS 1.3 na połączeniu. Złośliwy serwer może w rzadkich okolicznościach wykorzystać to do zdalnego wykonania kodu w kliencie.

curl w wersjach od 7.7 do 7.76.1 ujawnia informacje, gdy opcja wiersza poleceń `-t` (CURLOPT_TELNETOPTIONS w libcurl) jest używana do wysyłania par zmienna=wartość do serwerów TELNET. Błąd parsera opcji powodował przekazanie niezainicjalizowanych danych ze stosu do serwera.

curl w wersjach od 7.1.1 do 7.75.0 jest podatny na ujawnienie danych osobowych poprzez wyciek poświadczeń w nagłówku HTTP Referer. libcurl nie usuwa poświadczeń użytkownika z URL podczas automatycznego wypełniania pola nagłówka Referer w wychodzących żądaniach HTTP, co grozi wyciekiem wrażliwych danych do serwera docelowego drugiego żądania.

curl 7.41.0 do 7.73.0 jest podatny na nieprawidłowe sprawdzanie unieważnienia certyfikatu z powodu niewystarczającej weryfikacji odpowiedzi OCSP.

Złośliwy serwer może wykorzystać odpowiedź FTP PASV, aby nakłonić curl 7.73.0 i wcześniejsze do połączenia się z podanym adresem IP i portem. Umożliwia to potencjalne pozyskanie informacji o usługach, które normalnie są prywatne i nieujawnione.

curl w wersjach od 7.62.0 do 7.70.0 jest podatny na ujawnienie informacji, które może prowadzić do częściowego wycieku hasła przez sieć oraz do serwerów DNS.

Przy użyciu opcji --remote-header-name (-J) curl nie zachowuje udokumentowanej ochrony przed nadpisaniem pliku, jeśli pośrednia odpowiedź 103 Early Hints poprzedza końcową odpowiedź HTTP lub jeśli nagłówek ETag jest przetwarzany przed Content-Disposition w trybie --etag-save. Wada pozwala serwerowi HTTP(S) nadpisać istniejący plik lokalny wskazany w nagłówku Content-Disposition mimo ograniczenia -J.

Podczas zapisu długiej nazwy i wartości cookie do pliku cookie jar w formacie Netscape zdalny serwer HTTP może spowodować, że curl zapisze rekord przekraczający limit długości linii parsera. W konsekwencji każde kolejne wywołanie curl czytające z tego samego pliku cookie jar przez --cookie po cichu przerywa parsowanie na zbyt długiej linii, ignorując wszystkie kolejne prawidłowe cookies w pliku.

Włączenie CURLOPT_CRLF powoduje, że curl ogłasza w literale IMAP APPEND {N} surową liczbę bajtów wejściowych, podczas gdy przesyła dane z rozszerzonymi końcami linii. Serwer odczytuje tylko N bajtów ładunku, powodując że pozostałe nadmiarowe bajty są interpretowane i wykonywane jako wstrzyknięte polecenia IMAP w uwierzytelnionej sesji.

Złośliwe lub błędne źródło HTTPS może podać wartość HSTS max-age, którą parser akceptuje, ale której serializacja czasu później nie przetwarza. Na systemach 64-bitowych skrajne wartości max-age powodują przekroczenie granic struktur czasu kalendarzowego. Podczas zapisu cache plik HSTS jest obcinany przed zapisem pliku tymczasowego, a błąd serializacji jest po cichu ignorowany, co prowadzi do utraty danych przy jednoczesnym pomyślnym zakończeniu curl.

Importowanie wpisu HSTS nadrzędnego z includeSubDomains przed wpisem podrzędnym o dłuższym czasie ważności powoduje ciche odrzucenie wpisu podrzędnego. Gdy wpis nadrzędny wygaśnie, ważna polityka HSTS podrzędna zostaje utracona, a curl wykonuje niezaszyfrowane żądania HTTP zamiast aktualizacji do HTTPS.

Funkcja dopasowania cache połączeń libcurl nie uwzględnia opcji automatycznego certyfikatu klienta, więc uwierzytelnione połączenie Schannel z cache może zostać przekazane transferowi przekierowanemu do innego originu. Dzieje się tak mimo jawnego wyłączenia opcji automatycznego certyfikatu klienta dla tego transferu.

Gdy opcja CURLOPT_INTERFACE (lub --interface) jest ustawiona z jednym z udokumentowanych prefiksów (if!, host!, ifhost!), powiązanie to nie jest częścią klucza ponownego użycia połączenia. Późniejszy transfer żądający innego źródła może po cichu użyć istniejącego połączenia i wyjść z adresu źródłowego wcześniejszego transferu.

Gdy curl jest zbudowany z GnuTLS, złośliwy serwer WebSocket może spowodować, że curl wyśle pamięć poza swój bufor wysyłania. Wynika to z odczytu poza granicami, gdy gnutls_record_send() zwraca liczbę wysłanych bajtów większą niż liczba bajtów przekazanych do wysłania, co GnuTLS robi po zablokowanym wysłaniu.

Zdalny serwer HTTP może ustawić cookie, które curl akceptuje i zapisuje do pliku cookie jar w formacie Netscape, ale nie może go ponownie wczytać. Przy następnym wywołaniu z tą samą ścieżką dla --cookie i --cookie-jar curl kończy się błędem przed połączeniem, a procedura czyszczenia zastępuje plik pustym, usuwając cookies dla niepowiązanych domen.

Błąd w logice narzędzia wiersza poleceń curl powoduje, że opcje weryfikacji hosta SSH są ustawiane tylko przy bezpośrednim połączeniu przez SFTP lub SCP, a nie w przypadku przekierowania. W efekcie po przekierowaniu weryfikacja hosta SSH może nie zostać włączona.

Ustawienie `CURLOPT_AWS_SIGV4` na NULL nie wyłącza uwierzytelniania SigV4, wbrew oczekiwaniom i dokumentacji. Kolejny transfer na tym samym uchwycie nadal wysyła nagłówek `Authorization: AWS4-HMAC-SHA256` do następnego adresu URL, ujawniając informacje o stanie.

Podatność w curl podczas przesyłania plików polega na nieprawidłowym obsłużeniu ramki HTTP/2 RST_STREAM otrzymanej od serwera, co prowadzi do użycia po zwolnieniu (use-after-free) obiektu struct Curl_easy.

Nagłówek Set-Cookie używający tabulatora (ASCII 9) zamiast spacji (ASCII 32) bezpośrednio przed atrybutem Secure powoduje, że curl zapisuje cookie bez flagi Secure. Cookie może być następnie błędnie wysyłane przez zwykły HTTP przy kolejnych żądaniach do tego samego hosta.

Podatność w curl powoduje, że przy użyciu schemeless URL z `--proto-default sftp` (lub scp) warstwa narzędzia pomija inicjalizację opcji bezpieczeństwa SSH, takich jak CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 i CURLOPT_SSH_KNOWNHOSTS, podczas gdy libcurl nawiązuje połączenie SFTP/SCP. W rezultacie curl łączy się z niezweryfikowanym hostem SSH bez zgłaszania błędu.

W curl brakuje górnego limitu alokacji pamięci dla niepotwierdzonych ramek WebSocket PING, co pozwala złośliwemu serwerowi na wyczerpanie całej dostępnej pamięci poprzez szybkie wysyłanie sekwencyjnych komunikatów PING.

Podatność w funkcji odbioru QUIC UDP w curl umożliwia złośliwemu serwerowi HTTP/3 wywołanie zdalnej odmowy usługi (DoS) na kliencie curl lub libcurl. Funkcja pomocnicza odrzuca puste datagramy UDP przed zliczeniem ich do budżetu pakietów na wywołanie, co pozwala połączonemu peerowi QUIC na ciągłe wysyłanie pustych datagramów, powodując nieokreślone blokowanie klienta.

curl może błędnie przekazać poświadczenia pierwszego proxy do drugiego proxy. Dzieje się tak, gdy: 1. curl jest skonfigurowany do używania różnych proxy dla różnych schematów URL, 2. pierwsze proxy wymaga poświadczeń, 3. drugie proxy nie używa poświadczeń, 4. podczas korzystania z pierwszego proxy (np. http://) curl jest proszony o podążenie za przekierowaniem do URL z innym schematem (np. https://), dostępnym przez drugie, inne proxy.

Gdy token bearer OAuth2 jest używany do transferu HTTP(S), a transfer wykonuje przekierowanie na drugi URL, curl może w pewnych okolicznościach wyciec ten token do drugiej nazwy hosta. Jeśli hostname, na który następuje przekierowanie, ma wpis w pliku .netrc ze słowem kluczowym machine lub default, curl przekaże token bearer ustawiony dla pierwszego hosta również do drugiego.

Podczas transferów SSH z użyciem SCP lub SFTP, gdy wymagane jest uwierzytelnianie kluczem publicznym, curl błędnie pyta i uwierzytelnia się przy użyciu lokalnie działającego agenta SSH.

Gdy token OAuth2 bearer jest używany do transferu HTTP(S) i transfer ten wykonuje przekierowanie między protokołami do drugiego URL używającego schematu IMAP, LDAP, POP3 lub SMTP, curl może błędnie przekazać token bearer do nowego hosta docelowego.

Przy użyciu opcji CURLOPT_PINNEDPUBLICKEY w libcurl lub --pinnedpubkey w narzędziu curl, curl powinien sprawdzać klucz publiczny certyfikatu serwera. Sprawdzenie to było pomijane w pewnym warunku, co pozwalało na nawiązanie połączenia bez weryfikacji i niezauważenie potencjalnego oszusta. Warunkiem było połączenie przez QUIC z ngtcp2 zbudowanym z GnuTLS oraz jawne wyłączenie standardowej weryfikacji certyfikatu.

W curl występuje błąd w logice porównywania ścieżek ciasteczek, który pozwala na odczyt poza granicą bufora sterty. Scenariusz obejmuje ciasteczko ustawione z atrybutem secure dla https://target, przekierowanie na http://target (ten sam host, jawny HTTP) i ponowne ustawienie tego samego ciasteczka ze ścieżką "/". Błąd powoduje awarię lub błędne wnioskowanie porównania, pozwalając niezabezpieczonej witrynie nadpisać zawartość bezpiecznego ciasteczka.

Kod WebSocket w curl nie aktualizował 32-bitowego wzorca maski dla każdej nowej wychodzącej ramki, zgodnie ze specyfikacją. Zamiast tego używał stałej maski przez cały czas trwania połączenia. Przewidywalny wzorzec maski umożliwia złośliwemu serwerowi wywołanie ruchu, który pośredniczące proxy może zinterpretować jako prawdziwy ruch HTTP i zatruć swój cache.

W curl istnieje podatność polegająca na tym, że przy jednoczesnym użyciu pliku .netrc do uwierzytelniania oraz podążaniu za przekierowaniami HTTP, hasło użyte dla pierwszego hosta może zostać ujawnione hostowi docelowemu. Luka występuje tylko wtedy, gdy plik netrc zawiera wpis 'default' bez loginu i hasła.

Gdy curl jest używany jednocześnie z plikiem .netrc do uwierzytelniania oraz do podążania za przekierowaniami HTTP, w pewnych okolicznościach może ujawnić hasło użyte dla pierwszego hosta hostowi docelowemu przekierowania. Wada występuje tylko wtedy, gdy plik netrc zawiera wpis pasujący do nazwy hosta docelowego przekierowania, ale wpis ten pomija samo hasło lub zarówno login, jak i hasło.