In de standaard C-bibliotheken uClibc en uClibc-ng, die in veel embedded en draagbare apparaten worden gebruikt, is een kwetsbaarheid geïdentificeerd (CVE niet toegewezen) waardoor fictieve gegevens in de DNS-cache kunnen worden ingevoegd, die kunnen worden gebruikt om het IP-adres te vervangen van een willekeurig domein in de cache en verzoeken omleiden naar het domein op de server van de aanvaller.
Het probleem treft verschillende Linux-firmwares voor routers, toegangspunten en Internet of Things-apparaten, evenals ingebedde Linux-distributies zoals OpenWRT en Embedded Gentoo. Opgemerkt wordt dat de kwetsbaarheid voorkomt in apparaten van veel fabrikanten (uClibc wordt bijvoorbeeld gebruikt in Linksys-, Netgear- en Axis-firmware), maar aangezien de kwetsbaarheid nog steeds niet is opgelost in uClibc en uClibc-ng, is gedetailleerde informatie over specifieke apparaten en fabrikanten waarvan de producten of het probleem beschikbaar is, zijn nog niet bekendgemaakt.
De kwetsbaarheid wordt veroorzaakt door het gebruik van voorspelbare transactie-ID's in de code voor het verzenden van DNS-query's. Het identificatienummer van het DNS-verzoek werd gekozen door eenvoudigweg de teller te verhogen zonder gebruik te maken van extra randomisatie van poortnummers, waardoor het mogelijk werd de DNS-cache te vergiftigen door het preventief verzenden van UDP-pakketten met fictieve antwoorden (het antwoord wordt geaccepteerd als het vóór het antwoord van de echte server en bevat de juiste ID). In tegenstelling tot de Kaminsky-methode die in 2008 werd voorgesteld, hoeft de transactie-ID niet eens te worden geraden, aangezien deze aanvankelijk voorspelbaar is (de waarde wordt aanvankelijk ingesteld op 1, die bij elk verzoek wordt verhoogd, in plaats van willekeurig te worden gekozen).
Om te beschermen tegen brute kracht van de identificatie, raadt de specificatie bovendien aan om een willekeurige verdeling te gebruiken van de aantallen bronnetwerkpoorten van waaruit DNS-verzoeken worden verzonden, wat de onvoldoende grote omvang van de identificatie compenseert. Wanneer u poortrandomisatie inschakelt om een fictief antwoord te genereren, moet u naast het selecteren van een 16-bits identificatie ook het netwerkpoortnummer selecteren. In uClibc en uClibc-ng was een dergelijke randomisatie niet expliciet ingeschakeld (bij het aanroepen van bind werd geen willekeurige UDP-bronpoort gespecificeerd) en het gebruik ervan was afhankelijk van de instellingen van het besturingssysteem.
Wanneer pot-randomisatie is uitgeschakeld, wordt het bepalen van de verhoogde aanvraag-ID gemarkeerd als een triviale taak. Maar zelfs als randomisatie wordt gebruikt, hoeft de aanvaller alleen maar de netwerkpoort te raden uit het bereik 32768-60999, waarvoor hij gebruik kan maken van het massaal gelijktijdig verzenden van fictieve antwoorden naar verschillende netwerkpoorten.
Het probleem is bevestigd in alle huidige releases van uClibc en uClibc-ng, inclusief de meest recente versies van uClibc 0.9.33.2 en uClibc-ng 1.0.40. In september 2021 werd informatie over de kwetsbaarheid naar CERT/CC gestuurd voor een gecoördineerde voorbereiding van oplossingen. In januari 2022 werden gegevens over het probleem gedeeld met meer dan 200 fabrikanten die samenwerken met CERT/CC. In maart werd geprobeerd afzonderlijk contact op te nemen met de beheerder van het uClibc-ng-project, maar hij antwoordde dat hij de kwetsbaarheid niet zelf kon oplossen en adviseerde om informatie over het probleem openbaar te maken, in de hoop hulp te krijgen bij het ontwikkelen van een repareren vanuit de gemeenschap. Onder de fabrikanten heeft NETGEAR de release aangekondigd van een update die de kwetsbaarheid wegneemt.
Bron: opennet.ru