Pirms dažām dienām tika izlaistas ziņas, ka C standarta bibliotēkās uClibc un uClibc-ng, ko izmanto daudzās iegultās un pārnēsājamās ierīcēs, ir konstatēta ievainojamība (ar CVE vēl nav piešķirts), kas ļauj aizstāt fiktīvus datus DNS kešatmiņā, ko var izmantot, lai izkrāptu kešatmiņā esoša patvaļīga domēna IP adresi un novirzītu pieprasījumus uz domēnu uz uzbrucēja serveri.
Par problēmu tiek minēts, ka šis ietekmē dažādu Linux programmaparatūru maršrutētājiem, piekļuves punktiem un IoT ierīcēm, kā arī iegultās Linux distribūcijas, piemēram, OpenWRT un Embedded Gentoo.
Par ievainojamību
Neaizsargātība Tas ir saistīts ar paredzamu darījumu identifikatoru izmantošanu kodā, lai nosūtītu vaicājumus no DNS. DNS vaicājuma ID tika izvēlēts, vienkārši palielinot skaitītāju bez turpmākas portu numuru nejaušināšanas, kas ļāva saindēt DNS kešatmiņu iepriekš nosūtot UDP paketes ar viltus atbildēm (atbilde tiks pieņemta, ja tā tiks saņemta pirms atbildes no reālā servera un ietver pareizu identifikāciju).
Atšķirībā no 2008. gadā piedāvātās Kaminska metodes, nav pat nepieciešams uzminēt darījuma ID, jo tas sākotnēji ir paredzams (sākotnēji tas ir iestatīts uz 1, kas palielinās ar katru pieprasījumu, un netiek izvēlēts nejauši).
lai pasargātu sevi pret ID minēšanu, specifikāciju turklāt iesaka izmantot tīkla portu numuru nejaušu sadalījumu izcelsmes, no kuras tiek sūtīti DNS vaicājumi, kas kompensē nepietiekamo ID lielumu.
Ja ir iespējota portu nejaušināšana, lai veidotu fiktīvu atbildi, papildus 16 bitu identifikatora izvēlei ir jāizvēlas arī tīkla porta numurs. Programmā uClibc un uClibc-ng šāda nejaušināšana nebija tieši iespējota (izsaucot saistīšanu, nejauša avota UDP ports netika norādīts), un tās ieviešana bija atkarīga no operētājsistēmas konfigurācijas.
Kad portu nejaušināšana ir atspējota, Palielināmā pieprasījuma ID noteikšana tiek atzīmēta kā nenozīmīgs uzdevums. Bet pat nejaušības gadījumā uzbrucējam ir tikai jāuzmin tīkla ports no diapazona 32768-60999, kuram viņš var izmantot masveida vienlaicīgu fiktīvu atbilžu sūtīšanu dažādos tīkla portos.
Problēma ir apstiprināts visās pašreizējās uClibc un uClibc-ng versijās, tostarp jaunākās uClibc 0.9.33.2 un uClibc-ng 1.0.40 versijas.
"Ir svarīgi atzīmēt, ka ievainojamība, kas ietekmē standarta C bibliotēku, var būt diezgan sarežģīta," komanda rakstīja emuāra ierakstā šonedēļ.
"Ne tikai simtiem vai tūkstošiem zvanu uz neaizsargāto funkciju vairākos punktos vienā programmā, bet arī ievainojamība ietekmētu nenoteiktu skaitu citu vairāku piegādātāju programmu, kas konfigurētas šīs bibliotēkas lietošanai."
2021. gada septembrī tika nosūtīta informācija par ievainojamību CERT/CC koordinētai masīva sagatavošanai. 2022. gada janvārī, problēma tika izplatīta ar vairāk nekā 200 ražotājiem saistīta ar CERT/CC.
Martā tika mēģināts atsevišķi sazināties ar uClibc-ng projekta uzturētāju, taču viņš atbildēja, ka pats nevar novērst ievainojamību, un ieteica publiski atklāt informāciju par problēmu, cerot saņemt palīdzību, izstrādājot labojumu. Sabiedrība. No ražotājiem NETGEAR paziņoja par atjauninājuma izlaišanu ar ievainojamības noņemšanu.
Ir svarīgi atzīmēt, ka ievainojamība, kas ietekmē standarta C bibliotēku, var būt diezgan sarežģīta. Ne tikai būtu simtiem vai tūkstošiem izsaukumu uz neaizsargāto funkciju vairākos punktos vienā programmā, bet arī ievainojamība ietekmētu nenoteiktu skaitu citu programmu no vairākiem piegādātājiem, kas konfigurēti šīs bibliotēkas lietošanai.
Tiek atzīmēts, ka ievainojamība izpaužas daudzu ražotāju ierīcēs (piemēram, uClibc tiek izmantots Linksys, Netgear un Axis programmaparatūrā), taču, tā kā uClibc un uClibc-ng ievainojamība joprojām nav aizlāpīta, detalizēta informācija par ierīcēm un konkrētiem ražotājiem, kuru produktos ir problēma, līdz tie tiek atklāti.
Beidzot ja jūs interesē uzzināt vairāk par to, varat pārbaudīt informāciju Šajā saitē.