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 beror på användningen av förutsägbara transaktionsidentifierare i koden för att skicka DNS-förfrågningar. Identifikationsnumret för DNS-förfrågan valdes genom att helt enkelt öka räknaren utan att använda ytterligare randomisering av portnummer, vilket gjorde det möjligt att förgifta DNS-cachen genom förebyggande sändning av UDP-paket med fiktiva svar (svaret kommer att accepteras om det anlände före svaret från den riktiga servern och inkluderar korrekt ID). Till skillnad från Kaminsky-metoden som föreslogs 2008, behöver transaktionsidentifieraren inte ens gissas, eftersom den initialt är förutsägbar (värdet är initialt satt till 1, som ökas med varje begäran, snarare än 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