In de standaard C-bibliotheken uClibc en uClibc-ng, die worden gebruikt in veel ingebedde en draagbare apparaten, is een kwetsbaarheid ontdekt (geen CVE toegekend), waarmee valse gegevens in de DNS-cache kunnen worden ingevoegd. Dit kan worden gebruikt om het IP-adres van een willekeurige domeinnaam in de cache te vervangen en verzoeken naar het domein naar de server van de aanvaller te omleiden.
Het probleem betreft verschillende Linux-firmware voor routers, toegangspunten en IoT-apparaten, evenals Linux-distributies voor ingebedde systemen zoals OpenWRT en Embedded Gentoo. Er wordt opgemerkt dat de kwetsbaarheid voorkomt in apparaten van veel fabrikanten (bijvoorbeeld wordt uClibc gebruikt in firmware van Linksys, Netgear en Axis), maar omdat de kwetsbaarheid in uClibc en uClibc-ng nog niet is verholpen, worden op dit moment geen gedetailleerde informatie over specifieke apparaten en fabrikanten die getroffen zijn door het probleem vrijgegeven.
De kwetsbaarheid wordt veroorzaakt door het gebruik van voorspelbare transactie-identificatie in de code voor het verzenden van DNS-verzoeken. Het identificatienummer van het DNS-verzoek werd gekozen door simpelweg de teller te verhogen zonder extra randomisatie van poortnummers toe te passen, wat het mogelijk maakte om de DNS-cache te besmetten via het proactief verzenden van UDP-pakketten met valse antwoorden (het antwoord wordt geaccepteerd als het eerder aankomt dan het echte antwoord en het bevat een correcte ID). de server In tegenstelling tot de in 2008 voorgestelde methode van Kaminsky, hoeft het transactie-identificatienummer niet te worden gegokt, aangezien het van tevoren voorspelbaar is (het begint met de waarde 1, die bij elk verzoek wordt verhoogd en niet willekeurig wordt gekozen).
In de specificatie voor bescherming tegen het raden van identificaties wordt aanbevolen om daarnaast een willekeurige verdeling van de doelpoorten te gebruiken vanwaar DNS-verzoeken worden verzonden, om te compenseren voor de onvoldoende grote grootte van de identificatie. Bij het inschakelen van poortrandomisatie voor het genereren van een valse respons, moet naast het raden van het 16-bits identificatienummer ook het netwerkpoortnummer worden geraden. In uClibc en uClibc-ng was een dergelijke randomisatie niet expliciet ingeschakeld (bij het aanroepen van bind werd er geen willekeurige uitgangs-UDP-poort opgegeven) en de toepassing ervan was afhankelijk van de instellingen van het besturingssysteem.
Bij het uitschakelen van de randomisatie van de poorten wordt het bepalen van de incrementele verzoekidentificator als een triviale taak beschouwd. Maar zelfs als randomisatie wordt toegepast, hoeft de aanvaller slechts de netwerkpoort te raden uit het bereik van 32768ā60999, waarvoor massale gelijktijdige verzending van valse antwoorden op verschillende netwerkpoorten kan worden gebruikt.
Het probleem is bevestigd in alle actuele versies van uClibc en uClibc-ng, inclusief de nieuwste 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 gecoƶrdineerde voorbereiding van patches. In januari 2022 werden gegevens over het probleem aan meer dan 200 fabrikanten doorgegeven die samenwerken met CERT/CC. In maart werd er geprobeerd om afzonderlijk contact op te nemen met het project uClibc-ng, maar zij reageerden dat ze niet in staat waren om de kwetsbaarheid alleen op te lossen en adviseerden om informatie over het probleem openbaar te maken, in de hoop hulp te krijgen van de gemeenschap bij het ontwikkelen van een patch. Van de fabrikanten heeft NETGEAR aangekondigd een update ter oplossing van de kwetsbaarheid uit te geven.
Bron: opennet.ru
