In die standaard C-biblioteke uClibc en uClibc-ng, wat in baie ingebedde en draagbare toestelle gebruik word, is 'n kwesbaarheid geïdentifiseer (CVE nie toegewys nie) wat toelaat dat fiktiewe data in die DNS-kas ingevoeg word, wat gebruik kan word om die IP-adres te vervang van 'n arbitrêre domein in die kas en herlei versoeke na die domein op die aanvaller se bediener.
Die probleem raak verskeie Linux-firmware vir routers, toegangspunte en Internet of Things-toestelle, sowel as ingebedde Linux-verspreidings soos OpenWRT en Embedded Gentoo. Daar word kennis geneem dat die kwesbaarheid in toestelle van baie vervaardigers voorkom (uClibc word byvoorbeeld in Linksys, Netgear en Axis-firmware gebruik), maar aangesien die kwesbaarheid in uClibc en uClibc-ng onopgelos bly, gedetailleerde inligting oor spesifieke toestelle en vervaardigers wie se produkte die probleem is beskikbaar. is nog nie bekend gemaak nie.
Die kwesbaarheid is te wyte aan die gebruik van voorspelbare transaksie-identifiseerders in die kode vir die stuur van DNS-navrae. Die identifikasienommer van die DNS-versoek is gekies deur bloot die teller te verhoog sonder om addisionele ewekansige poortnommers te gebruik, wat dit moontlik gemaak het om die DNS-kas te vergiftig deur voorkomende stuur van UDP-pakkies met fiktiewe antwoorde (die antwoord sal aanvaar word as dit voor die antwoord van die regte bediener en sluit die korrekte ID in). Anders as die Kaminsky-metode wat in 2008 voorgestel is, hoef die transaksie-identifiseerder nie eers geraai te word nie, aangesien dit aanvanklik voorspelbaar is (die waarde word aanvanklik op 1 gestel, wat met elke versoek verhoog word, eerder as om lukraak gekies te word).
Om te beskerm teen brute force van identifiseerder, beveel die spesifikasie ook aan om 'n ewekansige verspreiding van getalle bronnetwerkpoorte te gebruik waarvandaan DNS-versoeke gestuur word, wat vergoed vir die onvoldoende groot grootte van die identifiseerder. Wanneer jy poort-randomisering aktiveer om 'n fiktiewe reaksie te genereer, moet jy benewens die keuse van 'n 16-bis identifiseerder ook die netwerkpoortnommer kies. In uClibc en uClibc-ng is sulke ewekansigheid nie eksplisiet geaktiveer nie (wanneer bind gebel word, is 'n ewekansige bron UDP-poort nie gespesifiseer nie) en die gebruik daarvan het van die bedryfstelselinstellings afgehang.
Wanneer pot-randomisering gedeaktiveer is, word die bepaling van die verhoogde versoek-ID as 'n onbenullige taak gemerk. Maar selfs al word ewekansigheid gebruik, hoef die aanvaller net die netwerkpoort van die reeks 32768–60999 te raai, waarvoor hulle massiewe gelyktydige versending van fiktiewe antwoorde na verskillende netwerkpoorte kan gebruik.
Die probleem is bevestig in alle huidige vrystellings van uClibc en uClibc-ng, insluitend die mees onlangse weergawes van uClibc 0.9.33.2 en uClibc-ng 1.0.40. In September 2021 is inligting oor die kwesbaarheid aan CERT/CC gestuur vir gekoördineerde voorbereiding van regstellings. In Januarie 2022 is data oor die probleem gedeel met meer as 200 vervaardigers wat met CERT/CC saamwerk. In Maart was daar 'n poging om die onderhouer van die uClibc-ng-projek afsonderlik te kontak, maar hy het geantwoord dat hy nie die kwesbaarheid op sy eie kon regstel nie en het aanbeveel om inligting oor die probleem in die openbaar bekend te maak, in die hoop om hulp te ontvang met die ontwikkeling van 'n regmaak van die gemeenskap. Onder die vervaardigers het NETGEAR die vrystelling van 'n opdatering aangekondig wat die kwesbaarheid uitskakel.
Bron: opennet.ru