Společnost Cloudflare oznámila odstranění tří zranitelností ve frameworku Pingora, dvě z nich mají kritickou úroveň nebezpečnosti (9.3 z 10). Framework Pingora je napsán v jazyce Rust a slouží k vývoji bezpečných vysoce výkonných síťových služeb. Proxy postavená pomocí Pingora se používá v síti pro doručování obsahu Cloudflare a zpracovává více než 40 milionů požadavků za sekundu. Zranitelnosti byly odstraněny ve verzi Pingora 0.8.0.
Dvě nejnebezpečnější zranitelnosti umožňují provádění útoků typu 'HTTP Request Smuggling', které umožňují obcházení systémů omezení přístupu a zasahování do obsahu požadavků jiných uživatelů zpracovávaných ve stejném toku mezi frontendem a backendem (například pro vložení škodlivého JavaScriptového kódu do relace jiného uživatele se stránkou). Problémy byly odhaleny účastníkem programu Bug Bounty, který zahrnuje odměny za odhalení zranitelností.
V režimu s voláním na backend přes zpětnou proxy přijímá požadavky klientů další uzel, který vytváří dlouhotrvající TCP připojení s backendem, který přímo zpracovává požadavky. Přes toto společné připojení se obvykle přenášejí požadavky různých uživatelů, které následují za sebou, oddělené prostředky protokolu HTTP. Útoky typu HTTP Request Smuggling vznikají z různých interpretací HTTP hlaviček a specifikací protokolu HTTP na frontendech a backendech, například když frontend používá pro určení velikosti požadavku hlavičku HTTP 'Content-Length', zatímco backend 'Transfer-Encoding: chunked'.
První zranitelnost CVE-2026-2835 je přítomna v kódu pro analýzu požadavků HTTP/1.0 a je způsobena nesprávným zpracováním hlavičky 'Transfer-Encoding' s více hodnotami, jakož i použitím uzavření spojení jako indikátoru konce těla požadavku (close-delimited). Pingora kontroloval pouze variantu 'Transfer-Encoding: chunked' a tuto hlavičku ignoroval, pokud obsahovala více hodnot. V této situaci Pingora nezohledňoval velikost v hlavičce 'Content-Length' a považoval za tělo požadavku všechna data přijatá do uzavření spojení.
Zadáním několika hodnot v hlavičce „Transfer-Encoding“ mohl útočník vytvořit podmínky, za kterých byl na backend přesměrován požadavek, jehož skutečná velikost neodpovídala velikosti chunked-řetězce vypočteného na základě hlavičky „Transfer-Encoding“. Pingora přesměrovával všechny přijímané údaje jako jeden požadavek, a backend, například Node.js, vypočítával požadavek na základě „Transfer-Encoding: chunked“ a zbytek zpracovával jako začátek jiného požadavku. GET / HTTP/1.0 Host: example.com Connection: keep-alive Transfer-Encoding: identity, chunked Content-Length: 29 0 GET /admin HTTP/1.1 X:
Druhá zranitelnost CVE-2026-2833 je způsobena nesprávným zpracováním HTTP hlavičky „Upgrade“ v požadavcích HTTP/1.1. Při přítomnosti hlavičky „Upgrade“ v požadavku proxy ihned předala backendu a ostatní údaje požadavku, které následovaly za hlavičkou „Upgrade“, aniž by čekala na odpověď backendu s kódem 101 (Switching Protocols). V důsledku toho byla synchronizace toku mezi proxy a backendem narušena a backend vnímal zaslané údaje po hlavičce „Upgrade“ jako samostatný požadavek a posílal výsledek vykonání tohoto požadavku jako odpověď na přicházející následný požadavek od jiného uživatele. GET / HTTP/1.1 Host: example.com Upgrade: foo GET /admin HTTP/1.1 Host: example.com
Problémy se projevují při použití Pingora ve formě zpětného proxy (ingress proxy), který přenáší požadavky uživatelů na backendy s použitím protokolů HTTP/1.0 nebo HTTP/1.1. Použitá v síti doručování obsahu Cloudflare konfigurace Pingora nedovolovala exploataci zranitelností, protože Pingora v CDN nefunguje jako ingress-proxy, přesměrovává požadavky pouze s použitím protokolu HTTP/1.1, blokuje požadavky s nesprávnými hodnotami Content-Length, přesměrovává pouze jednu hodnotu hlavičky „Transfer-Encoding: chunked“ a do požadavků s hlavičkou „Upgrade:“ vkládá další hlavičku „Connection: close“, která neumožňuje přenášet další požadavky ve stejném spojení.
Třetí zranitelnost CVE-2026-2836 (stupně nebezpečnosti 8,4 z 10) vede k zamoření cache (cache poisoning) kvůli generování klíče pro ukládání dat v cache (CacheKey) pouze na základě cesty z URI, přičemž se ignoruje obsah hlavičky "Host". Taková nedostatečnost vede k vytváření stejných klíčů pro ukládání cache pro stejné HTTP cesty k různým hostitelům. Zranitelnost může být použita pro záměnu obsahu cache při používání režimu ukládání cache pro více hostitelů. V Pingora je ukládání cache experimentální funkcí, která není doporučována pro pracovní nasazení.
Zdroj: opennet.ru
