A standard C könyvtárakban, mint az uClibc és uClibc-ng, amelyek sok beágyazott és hordozható eszközben megtalálhatók, egy hiba (CVE nem lett hozzárendelve) került felfedezésre, amely lehetővé teszi hamis adatok beillesztését a DNS cache-be, amit arra lehet használni, hogy egy tetszőleges domain IP címét megváltoztassuk, így a domainhez intézett kéréseket a támadó szerverére irányíthatjuk.
A probléma különböző Linux firmware-eket érint a routerek, hozzáférési pontok és IoT eszközök számára, valamint olyan Linux disztribúciókat az beágyazott rendszerekhez, mint az OpenWRT és az Embedded Gentoo. Jelentették, hogy a hiba számos gyártó eszközeiben megjelenik (például az uClibc-t a Linksys, Netgear és Axis firmware-jeiben használják), de mivel a uClibc és uClibc-ng hibái még nem lettek javítva, a konkrét eszközökről és gyártókról, amelyekben a probléma megtalálható, részletes információk még nem kerültek nyilvánosságra.
A hiba a DNS-kérések küldésében használt előre megjósolható tranzakciós azonosítók alkalmazásából ered. A DNS kérés azonosítója egyszerű számláló növelésével lett kiválasztva, anélkül hogy további port randomizálásra került volna sor, ami lehetővé tette a DNS cache megsértését várakoztatott UDP csomagok küldésével hamis válaszokkal (a válasz elfogadásra kerül, ha az korábban érkezik, mint a valódi válasz és tartalmazza a megfelelő ID-t). a szerver Ezzel szemben a 2008-ban javasolt Kaminsky-módszerrel, a tranzakció azonosítóját még csak nem is kell kitalálni, mivel az alapvetően előre megjósolható (eleinte az érték 1-re van beállítva, amely minden kérés után növekszik, nem pedig véletlenszerűen van kiválasztva).
A kivédekezés érdekében ajánlott további véletlenszerű eloszlást alkalmazni azon hálózati portok számánál, ahonnan DNS-kéréseket küldenek, ami kompenzálja az azonosító elégtelen méretét. A portok véletlenszerűsítésének engedélyezésével a hamis válasz generálása során nemcsak a 16 bites azonosítót kell kitalálni, hanem a hálózati port számát is. Az uClibc és uClibc-ng esetében az ilyen véletlenszerűsítést nem állították be kifejezetten (a bind hívásakor nem volt megadva véletlenszerű kimeneti UDP port), és alkalmazása az operációs rendszer beállításaitól függött.
A randomization of requests makes it trivial to define the incrementing request identifier. However, even with randomization, the attacker only needs to guess the network port from the range of 32768–60999, which can be achieved through massive simultaneous sending of fake responses across different network ports.
The issue has been confirmed in all current releases of uClibc and uClibc-ng, including the latest versions uClibc 0.9.33.2 and uClibc-ng 1.0.40. In September 2021, information about the vulnerability was sent to CERT/CC for coordinated preparation of fixes. In January 2022, data about the problem were passed to over 200 manufacturers collaborating with CERT/CC. In March, there was an attempt to contact the maintainer of the uClibc-ng project separately, but he responded that he was unable to fix the vulnerability himself and recommended publicly disclosing information about the issue, hoping to receive help in developing a fix from the community. NETGEAR was the only manufacturer to announce the release of an update addressing the vulnerability.
Forrás: opennet.ru
