I standard C-biblioteken uClibc och uClibc-ng, som används i många inbäddade och bärbara enheter, har en sårbarhet identifierats (CVE ej tilldelad) som gör att fiktiv data kan infogas i DNS-cachen, som kan användas för att ersätta IP-adressen av en godtycklig domän i cachen och omdirigera förfrågningar till domänen på angriparens server.
Problemet påverkar olika Linux-firmwares för routrar, åtkomstpunkter och Internet of Things-enheter, såväl som inbäddade Linux-distributioner som OpenWRT och Embedded Gentoo. Det noteras att sårbarheten förekommer i enheter från många tillverkare (till exempel används uClibc i Linksys, Netgear och Axis firmware), men eftersom sårbarheten förblir ofixad i uClibc och uClibc-ng, detaljerad information om specifika enheter och tillverkare vars produkter har problemet är tillgängligt. har ännu inte avslöjats.
Sårbarheten orsakas av användningen av förutsägbara transaktionsidentifierare i DNS-frågekoden. DNS-fråge-ID:t valdes genom att helt enkelt öka en räknare utan ytterligare slumpmässig portnummerhantering, vilket möjliggjorde DNS-cacheförgiftning genom att i förväg skicka UDP-paket med falska svar (svaret skulle accepteras om det anlände före det riktiga svaret). server och inkluderar rätt ID). Till skillnad från Kaminskys metod som föreslogs 2008 behöver transaktions-ID:t inte ens gissas, eftersom det initialt är förutsägbart (det är initialt inställt på 1, vilket ökas med varje begäran, snarare än att väljas slumpmässigt).
För att skydda mot brute force av identifierare rekommenderar specifikationen att man dessutom använder en slumpmässig fördelning av antalet källnätverksportar från vilka DNS-förfrågningar skickas, vilket kompenserar för den otillräckliga storleken på identifieraren. När du aktiverar portrandomisering för att generera ett fiktivt svar måste du förutom att välja en 16-bitars identifierare också välja nätverksportnumret. I uClibc och uClibc-ng var sådan randomisering inte uttryckligen aktiverad (när bindning anropades specificerades inte en slumpmässig källa UDP-port) och dess användning berodde på operativsystemets inställningar.
När pottrandomisering är inaktiverad markeras fastställandet av det inkrementerade begäran-ID som en trivial uppgift. Men även om randomisering används behöver angriparen bara gissa nätverksporten från intervallet 32768–60999, för vilken de kan använda massiv samtidig sändning av fiktiva svar till olika nätverksportar.
Problemet har bekräftats i alla aktuella versioner av uClibc och uClibc-ng, inklusive de senaste versionerna av uClibc 0.9.33.2 och uClibc-ng 1.0.40. I september 2021 skickades information om sårbarheten till CERT/CC för samordnad förberedelse av korrigeringar. I januari 2022 delades data om problemet med mer än 200 tillverkare som samarbetade med CERT/CC. I mars gjordes ett försök att separat kontakta underhållaren av uClibc-ng-projektet, men han svarade att han inte kunde åtgärda sårbarheten på egen hand och rekommenderade att offentliggöra information om problemet, i hopp om att få hjälp med att utveckla en fixa från samhället. Bland tillverkarna tillkännagav NETGEAR lanseringen av en uppdatering som eliminerar sårbarheten.
Källa: opennet.ru
