NĂ« bibliotekat standarde C uClibc dhe uClibc-ng, tĂ« pĂ«rdorura nĂ« shumĂ« pajisje tĂ« integruara dhe portative, Ă«shtĂ« zbuluar njĂ« vulnerabilitet (CVE nuk Ă«shtĂ« caktuar), qĂ« lejon futjen e tĂ« dhĂ«nave tĂ« rreme nĂ« cache-n e DNS, gjĂ« qĂ« mund tĂ« pĂ«rdoret pĂ«r tĂ« ndĂ«rruar IP-nĂ« e njĂ« ĐŽĐŸĐŒene tĂ« rastĂ«sishme nĂ« cache dhe pĂ«r tĂ« redirigjuar kĂ«rkesat e domenit nĂ« serverin e sulmuesit.
Problemi ndikon në disa firmware Linux për router-a, pika access dhe pajisje të internetit të gjërave, si dhe distribuime Linux për sisteme të integruara, si OpenWRT dhe Embedded Gentoo. Raportohet se vulnerabiliteti manifeston në pajisjet e shumë prodhuesve (për shembull, uClibc përdoret në firmware-t e Linksys, Netgear dhe Axis), por përderisa vulnerabiliteti në uClibc dhe uClibc-ng nuk është ndrequr, informacionet e detajuara mbi pajisjet specifike dhe prodhuesit, në produktet e të cilëve paraqitet problemi, ende nuk janë zbuluar.
Vulnerabiliteti shkaktohet nga përdorimi i identifikuesve të parashikueshëm të transaksioneve në kodin e dërgimit të kërkesave DNS. Numri identifikues i kërkesës DNS zgjidhej duke rritur thjesht një numër të count-it pa aplikuar ndonjë randomizim shtesë të numrave të porteve, çka lejonte rrethimin e cache-it të DNS përmes dërgimin e parashikueshëm të paketimeve UDP me përgjigje të rreme (përgjigja do të merret nëse arrin më herët se përgjigja e vërtetë dhe përfshin ID-në e saktë). serverë Ndryshe nga metoda e propozuar në vitin 2008 nga Kaminski, identifikuesi i transaksionit as duhet të gjuhet, pasi që ai është fillimisht i parashikueshëm (fillimisht i caktohet vlera 1, e cila rritet me çdo kërkesë, dhe nuk zgjedhet rastësisht).
Në specifikimin për mbrojtjen nga gjetja e identifikuesit, rekomandohet që të aplikohet gjithashtu shpërndarja rastësore e numrave të porteve të rrjetit nga të cilët dërgohen kërkesat DNS, gjë që kompenzon për madhësinë jo mjaft të madhe të identifikuesit. Me aktivizimin e randomizimit të porteve për formimin e përgjigjes së rreme, përveç gjetjes së identifikuesit të 16 bitëve, gjithashtu duhet të gjendet numri i portit të rrjetit. Në uClibc dhe uClibc-ng një randomizim i tillë nuk është përfshirë shprehimisht (në thirrjen bind nuk është caktuar një port UDP i rastësishëm) dhe zbatimi i saj varej nga konfigurimet e sistemit operativ.
Kur gjatĂ« çaktivizimit tĂ« randomizimit tĂ« seancĂ«s, pĂ«rcaktimi i identifikuesit inkrementues tĂ« kĂ«rkesĂ«s shĂ«nohet si njĂ« detyrĂ« triviale. Por edhe nĂ« rastin e pĂ«rdorimit tĂ« randomizimit, sulmuesi duhet thjesht tĂ« guess njĂ« port rrjeti nga diapazoni 32768â60999, pĂ«r tĂ« cilin mund tĂ« pĂ«rdorĂ« dĂ«rgimin masiv tĂ« pĂ«rgjigjeve tĂ« rreme nĂ«pĂ«rmjet porteve tĂ« ndryshme tĂ« rrjetit.
Prania e problemit është e konfirmuar në të gjitha versionet aktuale të uClibc dhe uClibc-ng, përfshirë versionet më të fundit uClibc 0.9.33.2 dhe uClibc-ng 1.0.40. Në muajin shtator 2021, informacioni mbi dobësinë u dërgua në CERT/CC për përgatitjen e koordinuar të rregullimeve. Në janar 2022, të dhënat mbi problemin iu kaluan mbi 200 prodhuesve, që bashkëpunojnë me CERT/CC. Në mars, u bë një përpjekje për t'u lidhur veçmas me menaxherin e projektit uClibc-ng, por ai u përgjigj se nuk ishte në gjendje të rregullonte dobësinë vetë dhe rekomandoi të zbulohej publikuar informacioni mbi problemin, duke shpresuar të merrte ndihmë për zhvillimin e një rregullimi nga komuniteti. Nga prodhuesit, NETGEAR njoftoi për lëshimin e një përditësimi që rregullon dobësinë.
Burimi: opennet.ru
