W narzędziu do przesyłania i odbierania danych sieciowych curl oraz rozwijającej się równolegle bibliotece libcurl zidentyfikowano podatność (CVE-2023-38545), która może prowadzić do przepełnienia bufora i potencjalnie do wykonania kodu atakującego po stronie klienta, gdy narzędzie curl lub aplikacja wykorzystująca libcurl łączy się z serwerem HTTPS kontrolowanym przez przestępcę. Problem występuje tylko w przypadku włączenia w curl dostępu przez proxy SOCKS5. W przypadku bezpośredniego połączenia bez proxy podatność się nie ujawnia. Podatność została usunięta w wydaniu curl 8.4.0. Badacz bezpieczeństwa, który wykrył błąd, otrzymał nagrodę w wysokości 4660 USD w ramach inicjatywy Internet Bug Bounty na Hackerone.
Podatność jest spowodowana błędem w kodzie rozwiązywania nazw hostów przed połączeniem z proxy SOCKS5. Przy długości nazwy hosta do 256 znaków curl natychmiast przekazuje nazwę do proxy SOCKS5 do rozwiązania, a jeśli nazwa ma więcej niż 255 znaków, przełącza się na lokalny resolver i przekazuje już określony adres do SOCKS5. Z powodu błędu w kodzie flaga wskazująca na konieczność lokalnego rozwiązania mogła zostać ustawiona na niewłaściwą wartość podczas wolnego negocjowania połączenia przez SOCKS5, co prowadziło do zapisania długiej nazwy hosta w buforze przygotowanym na zapisanie adresy IP lub nazwy nieprzekraczającej 255 znaków.
Właściciel witryny, do której curl łączy się przez proxy SOCKS5, może inicjować przepełnienie bufora po stronie klienta, zwracając w odpowiedzi kod przekierowania żądania (HTTP 30x) i ustawiając w nagłówku „Location:” URL z nazwą hosta o rozmiarze mieszczącym się w zakresie od 16 do 64 KB (wartość 16 KB wynika z minimalnego rozmiaru koniecznego do przepełnienia alokowanego bufora, a wartość 65 KB związana jest z maksymalną dozwoloną długością nazwy hosta w URL). Jeśli w ustawieniach libcurl dozwolone jest przekierowanie żądań, a używane proxy SOCKS5 jest wystarczająco wolne, to długa nazwa hosta zostanie zapisana w małym buforze, zdecydowanie mniejszym rozmiarze.
Podatność dotyczy głównie aplikacji opartych na libcurl i objawia się w narzędziu curl tylko podczas używania opcji „—limit-rate” z wartością mniejszą niż 65541 — w libcurl domyślnie alokowany jest bufor o rozmiarze 16 KB, a w narzędziu curl — 100 KB, ale ten rozmiar zmienia się w zależności od wartości parametru „—limit-rate”.
Daniel Stenberg, autor projektu, wspomniał, że luka pozostała niezauważona przez 1315 dni. Zostało również stwierdzone, że 41% wcześniej wykrytych luk w curl można by uniknąć, gdyby curl był napisany w języku zapewniającym bezpieczną obsługę pamięci, ale przepisywanie curl na inny język w przewidywalnej przyszłości nie jest planowane. W ramach działań na rzecz zwiększenia bezpieczeństwa bazy kodu proponuje się rozszerzenie narzędzi do testowania kodu oraz aktywniejsze wykorzystywanie zależności napisanych w językach programowania, które zapewniają bezpieczną obsługę pamięci. Rozważana jest również stopniowa wymiana części curl na wersje napisane w bezpiecznych językach, takich jak eksperymentalny backend HTTP Hyper, zrealizowany w języku Rust.
Źródło: opennet.ru
