Eng Schwachstelle bei uClibc an uClibc-ng déi et erlaabt Daten am DNS-Cache ze spoofen

An de Standard C Bibliothéiken uClibc an uClibc-ng, déi a ville embedded a portable Geräter benotzt ginn, gouf eng Schwachstelle identifizéiert (CVE net zougewisen), déi et erlaabt fiktiv Donnéeën an den DNS Cache agebaut ze ginn, déi benotzt kënne fir d'IP Adress z'ersetzen. vun engem arbiträren Domain am Cache a Viruleedungsufroen op d'Domain um Server vum Ugräifer.

D'Thema beaflosst verschidde Linux Firmware fir Router, Access Points, an Internet of Things Geräter, souwéi embedded Linux Distributiounen wéi OpenWRT an Embedded Gentoo. Et gëtt bemierkt datt d'Schwachheet an Apparater vu ville Hiersteller erschéngt (zum Beispill uClibc gëtt a Linksys, Netgear an Axis Firmware benotzt), awer well d'Schwachheet an uClibc an uClibc-ng onfix bleift, detailléiert Informatioun iwwer spezifesch Apparater an Hiersteller deenen hir Produkter hunn de Problem verfügbar. sinn nach net bekanntginn.

D'Schwachheet ass wéinst der Benotzung vu prévisibel Transaktiounsidentifizéierer am Code fir DNS Ufroen ze schécken. D'Identifikatiounsnummer vun der DNS-Ufro gouf gewielt andeems de Konter einfach erhéicht gouf ouni zousätzlech Randomiséierung vu Portnummeren ze benotzen, wat et méiglech gemaach huet den DNS-Cache ze vergëften duerch preemptive Sendung vun UDP-Päckchen mat fiktiven Äntwerten (d'Äntwert gëtt ugeholl wann se virdru ukomm ass) d'Äntwert vum richtege Server an enthält déi richteg ID). Am Géigesaz zu der Kaminsky Method, déi am Joer 2008 proposéiert gouf, brauch den Transaktiounsidentifizéierer net emol ze roden, well et am Ufank prévisibel ass (de Wäert ass ufanks op 1 gesat, dee mat all Ufro eropgeet, anstatt zoufälleg gewielt).

Eng Schwachstelle bei uClibc an uClibc-ng déi et erlaabt Daten am DNS-Cache ze spoofen

Fir géint Identifizéierer brute Kraaft ze schützen, recommandéiert d'Spezifikatioun zousätzlech eng zoufälleg Verdeelung vun Zuelen vu Quellnetzhäfen ze benotzen, aus deenen DNS Ufroe geschéckt ginn, wat fir déi net genuch grouss Gréisst vum Identifizéierer kompenséiert. Wann Dir port randomization aktivéiert eng fiktiv Äntwert ze generéieren, Nieft engem wielt 16-bëssen Identifizéierer, Dir musst och d'Netz port Zuel wielt. An uClibc an uClibc-ng war sou Randomiséierung net explizit aktivéiert (wann Dir Bindung urufft, gouf e zoufälleg Quell UDP Hafen net spezifizéiert) a seng Notzung hänkt vun den Astellunge vum Betribssystem of.

Wann de Pot Randomiséierung behënnert ass, gëtt d'Bestëmmung vun der inkrementéierter Ufro-ID als eng trivial Aufgab markéiert. Awer och wann d'Randomiséierung benotzt gëtt, brauch den Ugräifer nëmmen den Netzhafen aus der Gamme 32768-60999 ze roden, fir déi se massiv simultan Sende vu fiktiven Äntwerten op verschidde Netzwierkporten benotze kënnen.

Eng Schwachstelle bei uClibc an uClibc-ng déi et erlaabt Daten am DNS-Cache ze spoofen

De Problem gouf an all aktuellen Verëffentlechungen vun uClibc an uClibc-ng bestätegt, dorënner déi lescht Versioune vun uClibc 0.9.33.2 an uClibc-ng 1.0.40. Am September 2021 gouf d'Informatioun iwwer d'Schwachheet un den CERT/CC geschéckt fir eng koordinéiert Virbereedung vu Fixer. Am Januar 2022 goufen Daten iwwer de Problem mat méi wéi 200 Hiersteller gedeelt, déi mam CERT/CC kollaboréieren. Am Mäerz gouf et e Versuch, den Erhalter vum uClibc-ng-Projet getrennt ze kontaktéieren, awer hien huet geäntwert datt hien net fäeg war d'Schwachheet eleng ze fixéieren a recommandéiert ëffentlech Informatioun iwwer de Problem z'erklären, an der Hoffnung Hëllef ze kréien bei der Entwécklung vun engem Problem. fix vun der Communautéit. Ënner den Hiersteller huet NETGEAR d'Verëffentlechung vun engem Update ugekënnegt, deen d'Schwachheet eliminéiert.

Source: opennet.ru

Setzt e Commentaire