Podatności curl

Gdy curl używa rozszerzenia TLS Certificate Status Request (OCSP stapling) do weryfikacji ważności certyfikatu serwera, może nie wykryć niektórych problemów OCSP i błędnie uznać odpowiedź za prawidłową. Jeśli zwrócony status wskazuje inny błąd niż 'revoked' (np. 'unauthorized'), nie jest traktowany jako zły certyfikat.

Gdy opcja wyboru protokołów wyłącza wszystkie protokoły bez dodania jakichkolwiek innych, domyślny zestaw protokołów pozostaje w zestawie dozwolonych z powodu błędu w logice usuwania protokołów. Wada występuje tylko wtedy, gdy wybór protokołów wyłącza cały dostępny zestaw, co jest mało prawdopodobne w rzeczywistych scenariuszach; zespół bezpieczeństwa curl ocenił ją jako niskiej wagi.

W curl 7.65.2 w pliku tool_operate.c występuje przepełnienie liczby całkowitej przy dużej wartości opóźnienia ponowienia (retry delay).

Podatność ujawnienia informacji w curl przed wersją 8.1.0 podczas transferów HTTP(S). Jeśli ten sam uchwyt był wcześniej użyty do żądania PUT z callbackiem odczytu, a następnie do POST z ustawionym CURLOPT_POSTFIELDS, libcurl może błędnie wywołać callback odczytu i wysłać niewłaściwe dane lub użyć pamięci po zwolnieniu.

Podatność w curl < v8.1.0 polega na nieprawidłowej walidacji certyfikatów podczas dopasowywania wzorców wieloznacznych w polu Subject Alternative Name certyfikatów serwera TLS. Wbudowana funkcja dopasowywania nazw w curl nieprawidłowo dopasowuje nazwy IDN (International Domain Name), co może skutkować akceptacją wzorców, które powinny zostać odrzucone.

Podatność typu denial of service w curl < v8.1.0 dotyczy sposobu, w jaki libcurl udostępnia różne backendy do rozwiązywania nazw hostów. W przypadku wbudowanego synchronicznego resolvera nazwy mogą powodować przekroczenie czasu wolnych operacji za pomocą alarm() i siglongjmp(), a libcurl używa globalnego bufora bez ochrony mutex, co w aplikacji wielowątkowej może prowadzić do awarii lub nieprawidłowego działania.

W curl < v8.1.0 istnieje podatność use-after-free w mechanizmie weryfikacji klucza publicznego serwera SSH za pomocą skrótu SHA 256 w libcurl. Gdy weryfikacja się nie powiedzie, libcurl zwalnia pamięć odcisku palca przed zwróceniem komunikatu o błędzie zawierającego ten (już zwolniony) skrót, co grozi wstawieniem poufnych danych ze sterty do komunikatu błędu.

W implementacji SFTP w curl przed wersją 8.0.0 występuje podatność path traversal polegająca na błędnym zastępowaniu znaku tyldy (~) użytego jako prefiks w pierwszym elemencie ścieżki. Atakujący mogą wykorzystać tę lukę do obejścia filtrowania lub wykonania dowolnego kodu, tworząc ścieżkę taką jak /~2/foo podczas dostępu do serwera z określonym użytkownikiem.

Podatność w curl przed wersją 7.88.0 polega na braku ograniczenia liczby kroków dekompresji przy łańcuchowych algorytmach kompresji HTTP. Limit był stosowany osobno dla każdego nagłówka, więc złośliwy serwer mógł wstawić praktycznie nieograniczoną liczbę kroków dekompresji, powodując wyczerpanie pamięci (malloc bomb).

W curl w wersji przed 7.88.0 występuje podatność polegająca na przesyłaniu danych w postaci jawnej (cleartext) z powodu nieprawidłowego działania mechanizmu HSTS przy równoległym żądaniu wielu adresów URL. Plik pamięci podręcznej HSTS jest nadpisywany przez ostatnio zakończone połączenie, przez co późniejsze żądanie HTTP do wcześniejszego hosta nie zostaje poprawnie przekierowane na HTTPS.

W curl w wersjach przed 7.87.0 występuje luka use-after-free. Gdy curl próbuje tunelować protokoły SMB lub TELNET przez proxy HTTP i zostanie odrzucony, w kodzie zamykania transferu używa zwolnionej struktury alokowanej na stercie.

curl może być poproszony o przetworzenie pliku .netrc w celu uzyskania poświadczeń. Jeśli plik kończy się linią z 4095 kolejnymi znakami niebędącymi białymi znakami i bez znaku nowej linii, curl najpierw odczyta poza bufor stosu, a jeśli odczyt się powiedzie, zapisze bajt zerowy poza jego granicami. W większości przypadków spowoduje to segfault lub podobny błąd, ale mogą wystąpić inne skutki.

Podatność double free w bibliotece curl w wersjach przed 7.86.0 (najwcześniejsza podatna wersja to 7.77.0). Występuje gdy curl używa proxy HTTP dla transferu z adresem URL o schemacie innym niż HTTP(S) (dict, gopher, gophers, ldap, ldaps, rtmp, rtmps lub telnet), a proxy odrzuci żądanie CONNECT zwracając kod inny niż 200.

Podczas pobierania i przetwarzania plików cookie z serwera HTTP(S) curl akceptuje pliki cookie zawierające znaki sterujące, które po odesłaniu do serwera HTTP mogą spowodować zwrócenie odpowiedzi 400. Umożliwia to witrynie "siostrzanej" przeprowadzenie ataku odmowy usługi wobec wszystkich powiązanych witryn.

curl posiada mechanizm HSTS, który wymusza połączenie HTTPS nawet gdy w URL podano HTTP. Podatność pozwala obejść ten mechanizm, jeśli nazwa hosta w URL zawiera kropkę na końcu, a wpis w pamięci HSTS jej nie zawiera (lub odwrotnie).

Parser adresów URL w curl błędnie akceptuje zakodowane procentowo separatory URL, takie jak '/', podczas dekodowania części nazwy hosta w adresie URL, tworząc *inny* adres URL z nieprawidłową nazwą hosta przy późniejszym pobieraniu. Na przykład adres URL taki jak `http://example.com%2F127.0.0.1/` zostałby zaakceptowany przez parser i przekształcony w `http://example.com/127.0.0.1/`. Ta wada może być wykorzystana do obejścia filtrów, kontroli i innych zabezpieczeń.

Podatność związana z nieprawidłowo rozwiązywaną nazwą została naprawiona w wersji 7.83.1. Może ona spowodować usunięcie niewłaściwego pliku, gdy opcje `--no-clobber` i `--remove-on-error` są używane jednocześnie.

W curl w wersjach od 7.65.0 do 7.82.0 występuje podatność na ujawnienie informacji, która pozwala na ponowne wykorzystanie połączenia przy użyciu adresu IPv6 z innego identyfikatora strefy.

Podatność w curl od wersji 4.9 do 7.82.0 włącznie, związana z niewystarczającą ochroną danych uwierzytelniających. Przy przekierowaniach HTTP(S) z uwierzytelnianiem może dojść do wycieku poświadczeń do innych usług działających na różnych protokołach lub portach.

W curl w wersjach od 7.33.0 do 7.82.0 występuje podatność związana z niewłaściwą autoryzacją, która może pozwolić na ponowne użycie połączeń uwierzytelnionych OAUTH2 bez odpowiedniego sprawdzenia, czy połączenie zostało uwierzytelnione tymi samymi poświadczeniami. Dotyczy to protokołów z obsługą SASL: SMPTP(S), IMAP(S), POP3(S) oraz LDAP(S) (tylko openldap).

W curl od wersji 7.20.0 do 7.78.0, podczas połączenia z serwerem IMAP lub POP3 przy użyciu STARTTLS, serwer może wysłać wiele odpowiedzi naraz, które curl buforuje. Po uaktualnieniu do TLS curl nadal ufa tym odpowiedziom, co pozwala atakującemu typu Man-In-The-Middle na wstrzyknięcie fałszywych odpowiedzi i oszukanie curl, by wysyłał dane do użytkownika, myśląc, że pochodzą z bezpiecznego serwera.

Gdy curl jest poinstruowany, aby pobrać zawartość za pomocą funkcji metalink, a do pobrania pliku XML metalink używane są nazwa użytkownika i hasło, te same poświadczenia są następnie przekazywane do każdego serwera, z którego curl będzie pobierać lub próbować pobrać zawartość. Często jest to sprzeczne z oczekiwaniami i intencjami użytkownika i bez informowania użytkownika o tym fakcie.

curl w wersjach od 7.61.0 do 7.76.1 cierpi na ujawnienie elementu danych do niewłaściwej sesji z powodu błędu w kodzie dla CURLOPT_SSL_CIPHER_LIST, gdy libcurl jest zbudowany z użyciem biblioteki TLS Schannel. Wybrany zestaw szyfrów był przechowywany w pojedynczej zmiennej "static" w bibliotece, co ma zaskakujący efekt uboczny: jeśli aplikacja ustawi wiele równoczesnych transferów, ostatni, który ustawi szyfry, przypadkowo kontroluje zestaw używany przez wszystkie transfery. W najgorszym przypadku znacznie osłabia to bezpieczeństwo transportu.

curl w wersjach od 7.63.0 do 7.75.0 włącznie zawiera podatność pozwalającą złośliwemu proxy HTTPS na atak MITM z powodu błędnej obsługi biletów sesji TLS 1.3. libcurl może pomylić bilety sesji pochodzące z proxy HTTPS z biletami z serwera zdalnego i użyć niewłaściwego biletu do wznowienia sesji.

Nieuprzywilejowany użytkownik lub program może umieścić kod i plik konfiguracyjny w znanej nieuprzywilejowanej ścieżce (pod C:/usr/local/), co spowoduje, że curl <= 7.65.1 automatycznie uruchomi ten kod (jako 'engine' OpenSSL) podczas wywołania. Jeśli curl jest wywoływany przez uprzywilejowanego użytkownika, może zrobić wszystko, co zechce.