A számos beágyazott és hordozható eszközben használt szabványos uClibc és uClibc-ng C-könyvtárban egy sérülékenységet azonosítottak (a CVE nincs hozzárendelve), amely lehetővé teszi fiktív adatok beillesztését a DNS-gyorsítótárba, amivel helyettesíthető az IP-cím. egy tetszőleges tartományt a gyorsítótárban, és irányítsa át a kéréseket a támadó szerverén lévő tartományra.
A probléma különféle Linux firmware-eket érint útválasztókhoz, hozzáférési pontokhoz és Internet of Things eszközökhöz, valamint a beágyazott Linux disztribúciókhoz, például az OpenWRT-hez és az Embedded Gentoo-hoz. Megjegyzendő, hogy a sérülékenység számos gyártó eszközén megjelenik (például az uClibc-t a Linksys, a Netgear és az Axis firmware-ben használják), de mivel a sérülékenység az uClibc-ben és az uClibc-ng-ben továbbra is javítatlan, részletes információk az egyes eszközökről és gyártókról, amelyek termékei a probléma elérhető. Még nem hozták nyilvánosságra.
A sérülékenység a DNS-lekérdezések küldésére szolgáló kódban előre látható tranzakció-azonosítók használatának köszönhető. A DNS-kérés azonosítószámát úgy választottuk ki, hogy egyszerűen növeltük a számlálót a portszámok további randomizálása nélkül, ami lehetővé tette a DNS-gyorsítótár mérgezését UDP-csomagok fiktív válaszokkal történő megelőző küldésével (a válasz elfogadásra kerül, ha korábban megérkezett). a válasz a valódi szervertől, és tartalmazza a helyes azonosítót). A 2008-ban javasolt Kaminsky-módszerrel ellentétben a tranzakcióazonosítót még csak kitalálni sem kell, mivel kezdetben megjósolható (az érték kezdetben 1-re van állítva, ami minden kéréssel növekszik, nem véletlenszerűen választva).
Az azonosítók brutális erővel szembeni védelme érdekében a specifikáció emellett a DNS-kéréseket elküldő forráshálózati portok számának véletlenszerű elosztását is javasolja, ami kompenzálja az azonosító nem kellően nagy méretét. Ha engedélyezi a port véletlenszerűsítését, hogy fiktív választ generáljon, a 16 bites azonosító kiválasztása mellett ki kell választania a hálózati port számát is. Az uClibc-ben és az uClibc-ng-ben az ilyen véletlenszerűsítés nem volt kifejezetten engedélyezve (a bind hívásakor véletlenszerű forrású UDP-port nem volt megadva), és használata az operációs rendszer beállításaitól függött.
Ha az edény véletlenszerűsítése le van tiltva, a megnövekedett kérésazonosító meghatározása triviális feladatként van megjelölve. De még véletlenszerűsítés alkalmazása esetén is a támadónak csak ki kell találnia a hálózati portot a 32768–60999 tartományból, amelyhez fiktív válaszok tömeges egyidejű küldését használhatja a különböző hálózati portokra.
A probléma az uClibc és az uClibc-ng összes jelenlegi kiadásában megerősítést nyert, beleértve az uClibc 0.9.33.2 és uClibc-ng 1.0.40 legújabb verzióit is. 2021 szeptemberében a sérülékenységgel kapcsolatos információkat elküldték a CERT/CC-nek a javítások összehangolt előkészítése érdekében. 2022 januárjában a problémára vonatkozó adatokat több mint 200, a CERT/CC-vel együttműködő gyártóval osztották meg. Márciusban külön megkísérelték felvenni a kapcsolatot az uClibc-ng projekt fenntartójával, de ő azt válaszolta, hogy egyedül nem tudja kijavítani a sérülékenységet, és javasolta a problémával kapcsolatos információk nyilvánosságra hozatalát, remélve, hogy segítséget kap a fejlesztéshez. javítás a közösségtől. A gyártók közül a NETGEAR jelentette be a biztonsági rést megszüntető frissítés kiadását.
Forrás: opennet.ru