cURL je softwarový projekt skládající se z knihovny a příkazového interpretu zaměřeného na přenos souborů.
Daniel Stenberg (autor projektu cURL) nedávno oznámil prostřednictvím příspěvku na blogu, informace o zranitelnost, která byla zjištěna v nástroj pro příjem a odesílání dat přes síť curl a knihovna libcurl.
Je zmíněno, že chyba zabezpečení (již katalogizovaná pod CVE-2023-38545) je způsobena chybou v kódu rozlišení názvu hostitele před přístupem k proxy SOCKS5.
SOCKS5 je proxy protokol. Jde o celkem jednoduchý protokol pro nastavení síťové komunikace přes dedikovaného „brokera“. Protokol se například obvykle používá při nastavování komunikace přes Tor, ale také pro přístup k internetu z organizací a společností.
SOCKS5 má dva různé režimy rozlišení názvu hostitele. Buď klient rozpozná název hostitele lokálně a předá cíl jako vyřešenou adresu, nebo klient předá plně kvalifikovaný název hostitele serveru proxy a umožní serveru proxy vyřešit hostitele vzdáleně.
Jako takové selhání může způsobit přetečení vyrovnávací paměti a potenciální spuštění kódu na straně klienta útočníka při přístupu k serveru HTTPS řízenému útočníkem prostřednictvím obslužného programu curl nebo aplikace, která používá libcurl. ale problém přítomen pouze při přístupu přes proxy SOCKS5 je povoleno zvlnění. Při přímém přístupu bez proxy se zranitelnost neobjeví.
Vlastník webu, ke kterému přistupuje curl prostřednictvím proxy serveru SOCKS5, je popsán jako schopný:
Spusťte přetečení vyrovnávací paměti na straně klienta vrácením kódu přesměrování požadavku (HTTP 30x) a nastavením záhlaví „Location:“ na adresu URL s názvem hostitele, jehož velikost se pohybuje od 16 do 64 kB (16 kB je maximální velikost). minimální požadované přetečení přiděleného bufferu a 65 KB je maximální povolená délka názvu hostitele v URL).
Pokud je v konfiguraci libcurl povoleno přesměrování požadavku a použitý proxy server SOCKS5 je dostatečně pomalý, pak se dlouhý název hostitele zapíše do malé vyrovnávací paměti, samozřejmě menší velikosti.
Ve svém příspěvku na blogu Daniel Stenberg zmínil, že zranitelnost zůstala nezjištěna po dobu 1315 XNUMX dní. Také říká, že 41 % dříve identifikovaných zranitelností v curl by se pravděpodobně dalo vyhnout, pokud by curl byl napsán v jazyce bezpečném pro paměť, ale v dohledné době se neplánuje přepsat curl do jiného jazyka.
Tato chyba zabezpečení se týká především aplikací založených na libcurl a objeví se v obslužném programu curl pouze při použití volby „–limit-rate“ s hodnotou menší než 65541, protože libcurl ve výchozím nastavení alokuje 16 KB vyrovnávací paměti a 100 KB v curl, ale tato velikost se mění v závislosti na hodnotě parametru „ parametr –limit-rate“.
Je zmíněno, že pokud je název hostitele do 256 znaků, curl okamžitě předá název proxy SOCKS5 k rozlišení, a pokud je název delší než 255 znaků, přepne se na lokální resolver a předá již definovanou adresu SOCKS5. . Kvůli chybě v kódu mohl být příznak indikující potřebu lokálního rozlišení během pomalého vyjednávání připojení přes SOCKS5 nastaven na nesprávnou hodnotu, což vedlo k zapsání dlouhého názvu hostitele do vyrovnávací paměti přiřazené s očekáváním uložení IP adresy. adresa nebo jméno, ne více než 255 znaků.
Nakonec je to zmíněno chyba zabezpečení byla opravena ve verzi curl 8.4.0 a jako opatření ke zlepšení bezpečnosti kódové základny se navrhuje rozšířit nástroje pro testování kódu a aktivněji využívat závislosti napsané v programovacích jazycích, které zaručují bezpečný provoz s pamětí. Zvažuje také postupné nahrazení částí curl volbami napsanými v bezpečných jazycích, jako je experimentální Hyper HTTP backend implementovaný v Rustu.
Pokud zájem dozvědět se o tom více, můžete zkontrolovat podrobnosti Na následujícím odkazu.