Před několika dny byla zveřejněna zpráva, že ve standardních knihovnách C uClibc a uClibc-ng, používané v mnoha vestavěných a přenosných zařízeních, byla zjištěna zranitelnost (s dosud nepřiřazeným CVE), což umožňuje náhradu fiktivních dat v mezipaměti DNS, pomocí kterých lze podvrhnout IP adresu libovolné domény v mezipaměti a přesměrovat požadavky na doménu na server útočníka.
O problému je zmíněno, že toto ovlivňuje různé linuxové firmwary pro routery, přístupové body a zařízení internetu věcí, stejně jako embedded linuxové distribuce jako OpenWRT a Embedded Gentoo.
O zranitelnosti
Zranitelnost je způsobeno používáním předvídatelných identifikátorů transakcí v kódu pro odesílání dotazů DNS. ID dotazu DNS bylo zvoleno prostým zvýšením počítadla bez další náhodnosti čísel portů, které umožnil otrávit mezipaměť DNS preemptivním odesíláním UDP paketů s falešnými odpověďmi (odpověď bude přijata, pokud dorazí před odpovědí ze skutečného serveru a bude obsahovat správnou identifikaci).
Na rozdíl od metody Kaminsky navržené v roce 2008 není ani nutné uhodnout ID transakce, protože je zpočátku předvídatelné (zpočátku je nastaveno na 1, která se zvyšuje s každým požadavkem a není vybíráno náhodně).
Chránit sebe proti hádání ID, specifikace dále doporučuje použití náhodného rozdělení čísel síťových portů původu, ze kterého jsou DNS dotazy odesílány, což kompenzuje nedostatečnou velikost ID.
Když je povolena náhodnost portů, je pro vytvoření fiktivní odpovědi kromě výběru 16bitového identifikátoru také nutné vybrat číslo síťového portu. V uClibc a uClibc-ng taková randomizace nebyla explicitně povolena (při volání bind nebyl specifikován náhodný zdrojový UDP port) a její implementace závisela na konfiguraci operačního systému.
Když je randomizace portů zakázána, určení, které ID požadavku se má zvýšit, je označeno jako triviální úkol. Ale i v případě randomizace stačí útočníkovi uhodnout síťový port z rozsahu 32768-60999, k čemuž může využít masivní simultánní odesílání fiktivních odpovědí na různé síťové porty.
Problém byl potvrzen ve všech aktuálních verzích uClibc a uClibc-ng, včetně nejnovějších verzí uClibc 0.9.33.2 a uClibc-ng 1.0.40.
„Je důležité si uvědomit, že zranitelnost ovlivňující standardní knihovnu C může být poměrně složitá,“ napsal tým tento týden v blogovém příspěvku.
"Nejen, že by došlo ke stovkám nebo tisícům volání zranitelné funkce na více místech v jediném programu, ale zranitelnost by ovlivnila neomezený počet dalších programů od různých výrobců nakonfigurovaných pro použití této knihovny."
V září 2021 byly odeslány informace o zranitelnosti na CERT/CC pro koordinovanou přípravu pole. V lednu 2022 problém byl sdílen s více než 200 výrobci spojené s CERT/CC.
V březnu došlo k pokusu samostatně kontaktovat správce projektu uClibc-ng, ale ten odpověděl, že sám nedokáže zranitelnost opravit, a doporučil veřejné zveřejnění informací o problému v naději, že získá pomoc s vývojem opravy. komunita. Od výrobců společnost NETGEAR oznámila vydání aktualizace s odstraněním zranitelnosti.
Je důležité poznamenat, že zranitelnost ovlivňující standardní knihovnu C může být poměrně složitá. Nejen, že by došlo ke stovkám nebo tisícům volání zranitelné funkce na více místech v jednom programu, ale zranitelnost by ovlivnila neomezený počet dalších programů od více dodavatelů nakonfigurovaných pro použití této knihovny.
Je třeba poznamenat, že zranitelnost se projevuje v zařízeních od mnoha výrobců (například uClibc se používá ve firmwaru od společností Linksys, Netgear a Axis), ale protože zranitelnost zůstává neopravena v uClibc a uClibc-ng, podrobné informace o zařízeních a konkrétní výrobci, v jejichž produktech je problém, dokud nebudou zveřejněny.
Konečně pokud máte zájem o tom vědět více, můžete zkontrolovat podrobnosti Na následujícím odkazu.