Een paar dagen geleden kwam het nieuws naar buiten dat in de C-standaardbibliotheken uClibc en uClibc-ng, gebruikt in veel ingebouwde en draagbare apparaten, er is een kwetsbaarheid vastgesteld (met CVE nog niet toegewezen), waarmee dummy-gegevens in de DNS-cache kunnen worden vervangen, die kunnen worden gebruikt om het IP-adres van een willekeurig domein in de cache te vervalsen en verzoeken om te leiden naar het domein naar de server van de aanvaller.
Over het probleem wordt vermeld dat dit beïnvloedt verschillende Linux-firmware voor routers, toegangspunten en IoT-apparaten, evenals embedded Linux-distributies zoals OpenWRT en Embedded Gentoo.
Over kwetsbaarheid
Kwetsbaarheid is te wijten aan het gebruik van voorspelbare transactie-ID's in de code om query's te verzenden van DNS. De DNS-query-ID werd gekozen door simpelweg de teller te verhogen zonder de poortnummers verder willekeurig te maken, wat: maakte het mogelijk om de DNS-cache te vergiftigen door preventief UDP-pakketten met valse antwoorden te verzenden (het antwoord wordt geaccepteerd als het vóór het antwoord van de echte server arriveert en de juiste identificatie bevat).
In tegenstelling tot de Kaminsky-methode die in 2008 werd voorgesteld, is het niet eens nodig om de transactie-ID te raden, omdat deze aanvankelijk voorspelbaar is (aanvankelijk is deze ingesteld op 1, die met elk verzoek toeneemt en niet willekeurig wordt geselecteerd).
om jezelf te beschermen tegen ID-gissing, de specificatie beveelt verder het gebruik van een willekeurige verdeling van netwerkpoortnummers aan van oorsprong van waaruit de DNS-query's worden verzonden, wat de onvoldoende grootte van de ID compenseert.
Als poortrandomisering is ingeschakeld, is het voor het vormen van een dummy-antwoord naast het selecteren van een 16-bits identificatie ook noodzakelijk om het netwerkpoortnummer te selecteren. In uClibc en uClibc-ng was dergelijke randomisatie niet expliciet ingeschakeld (wanneer bind werd aangeroepen, werd geen UDP-poort met willekeurige bron gespecificeerd) en de implementatie ervan was afhankelijk van de configuratie van het besturingssysteem.
Als poortrandomisatie is uitgeschakeld, bepalen welk verzoek-ID moet worden verhoogd, is gemarkeerd als een triviale taak. Maar zelfs in het geval van randomisatie hoeft de aanvaller alleen de netwerkpoort te raden uit het bereik 32768-60999, waarvoor hij massale gelijktijdige verzending van dummy-reacties op verschillende netwerkpoorten kan gebruiken.
Het probleem is bevestigd in alle huidige versies van uClibc en uClibc-ng, inclusief de nieuwste versies van uClibc 0.9.33.2 en uClibc-ng 1.0.40.
"Het is belangrijk op te merken dat een kwetsbaarheid die een standaard C-bibliotheek aantast, behoorlijk complex kan zijn", schreef het team deze week in een blogpost.
"Niet alleen zouden er honderden of duizenden oproepen naar de kwetsbare functie zijn op meerdere punten in een enkel programma, maar de kwetsbaarheid zou een onbepaald aantal andere multi-vendor-programma's beïnvloeden die zijn geconfigureerd om die bibliotheek te gebruiken."
In september 2021 is informatie over de kwetsbaarheid verzonden naar CERT/CC voor gecoördineerde arrayvoorbereiding. In januari 2022, het probleem werd gedeeld met meer dan 200 fabrikanten geassocieerd met CERT/CC.
In maart werd geprobeerd om 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 oplossing. de gemeenschap. Van de fabrikanten heeft NETGEAR de release aangekondigd van een update met het verwijderen van de kwetsbaarheid.
Het is belangrijk op te merken dat een kwetsbaarheid die een standaard C-bibliotheek aantast, behoorlijk complex kan zijn. Niet alleen zouden er honderden of duizenden oproepen naar de kwetsbare functie zijn op meerdere punten in een enkel programma, maar de kwetsbaarheid zou een onbepaald aantal andere programma's van meerdere leveranciers beïnvloeden die geconfigureerd zijn om die bibliotheek te gebruiken.
Opgemerkt wordt dat de kwetsbaarheid zich manifesteert in apparaten van veel fabrikanten (uClibc wordt bijvoorbeeld gebruikt in firmware van Linksys, Netgear en Axis), maar aangezien de kwetsbaarheid niet is gepatcht in uClibc en uClibc-ng, gedetailleerde informatie over apparaten en specifieke fabrikanten in wiens producten een probleem is, totdat ze worden onthuld.
Eindelijk als u er meer over wilt weten, kunt u de details bekijken In de volgende link.