Yn 'e standert C-biblioteken uClibc en uClibc-ng, brûkt yn in protte ynbêde en draachbere apparaten, is in kwetsberens identifisearre (CVE net tawiisd) wêrtroch fiktive gegevens yn 'e DNS-cache kinne wurde ynfoege, dy't kinne wurde brûkt om it IP-adres te ferfangen fan in willekeurich domein yn 'e cache en fersiken trochferwize nei it domein op' e tsjinner fan 'e oanfaller.
It probleem hat ynfloed op ferskate Linux-firmwares foar routers, tagongspunten, en Internet of Things-apparaten, lykas ynbêde Linux-distribúsjes lykas OpenWRT en Embedded Gentoo. It wurdt opmurken dat de kwetsberens ferskynt yn apparaten fan in protte fabrikanten (bygelyks, uClibc wurdt brûkt yn Linksys, Netgear en Axis firmware), mar sûnt de kwetsberens bliuwt unfixed yn uClibc en uClibc-ng, detaillearre ynformaasje oer spesifike apparaten en fabrikanten waans produkten hawwe it probleem beskikber. binne noch net bekend makke.
De kwetsberens komt troch it brûken fan foarsisbere transaksje-identifikaasjes yn 'e koade foar it ferstjoeren fan DNS-fragen. It identifikaasjenûmer fan it DNS-fersyk waard keazen troch gewoan de teller te ferheegjen sûnder ekstra randomisaasje fan poartenûmers te brûken, wat it mooglik makke om de DNS-cache te fergiftigjen troch preemptive ferstjoeren fan UDP-pakketten mei fiktive antwurden (it antwurd sil wurde akseptearre as it earder kaam it antwurd fan 'e echte server en omfettet de juste ID). Oars as de Kaminsky-metoade foarsteld yn 2008, hoecht de transaksje-identifikaasje net iens te rieden, om't it yn earste ynstânsje foarsisber is (de wearde is yn earste ynstânsje ynsteld op 1, dy't mei elk fersyk ferhege wurdt, ynstee fan willekeurich keazen).
Om te beskermjen tsjin brute krêft fan identifier, advisearret de spesifikaasje ek it brûken fan in willekeurige ferdieling fan oantallen boarne netwurkpoarten wêrfan DNS-oanfragen wurde ferstjoerd, wat kompensearret foar de net genôch grutte fan 'e identifier. As jo ynskeakelje port randomization foar in generearje in fiktyf antwurd, neist it selektearjen fan in 16-bit identifier, Jo moatte ek selektearje it netwurk haven nûmer. Yn uClibc en uClibc-ng wie sa'n randomisaasje net eksplisyt ynskeakele (by it oproppen fan bind, waard in willekeurige boarne UDP-poarte net oantsjutte) en it gebrûk wie ôfhinklik fan 'e bestjoeringssysteemynstellingen.
Wannear't pot randomization is útskeakele, bepale de ferhege fersyk ID wurdt markearre as in triviale taak. Mar sels as randomisaasje wurdt brûkt, hoecht de oanfaller allinich de netwurkpoarte te rieden fan it berik 32768–60999, wêrfoar se massive simultane ferstjoeren fan fiktive antwurden kinne brûke nei ferskate netwurkpoarten.
It probleem is befêstige yn alle aktuele releases fan uClibc en uClibc-ng, ynklusyf de meast resinte ferzjes fan uClibc 0.9.33.2 en uClibc-ng 1.0.40. Yn septimber 2021 waard ynformaasje oer de kwetsberens stjoerd nei CERT / CC foar koördinearre tarieding fan reparaasjes. Yn jannewaris 2022 waarden gegevens oer it probleem dield mei mear dan 200 fabrikanten dy't gearwurkje mei CERT/CC. Yn maart wie d'r in besykjen om apart kontakt op te nimmen mei de ûnderhâlder fan it uClibc-ng-projekt, mar hy antwurde dat hy de kwetsberens net sels koe reparearje en advisearre iepenbier iepenbierjen fan ynformaasje oer it probleem, yn 'e hope om help te ûntfangen by it ûntwikkeljen fan in fix út de mienskip. Under de fabrikanten kundige NETGEAR de frijlitting fan in update oan dy't de kwetsberens elimineert.
Boarne: opennet.ru