Acum câteva zile a fost lansată știrea că în bibliotecile standard C uClibc și uClibc-ng, utilizat în multe dispozitive încorporate și portabile, a fost identificată o vulnerabilitate (cu CVE încă nealocat), care permite înlocuirea datelor fictive în memoria cache DNS, care poate fi folosită pentru a falsifica adresa IP a unui domeniu arbitrar în cache și pentru a redirecționa cererile către domeniu către serverul atacatorului.
Despre problema se mentioneaza ca aceasta afectează diverse firmware-uri Linux pentru routere, puncte de acces și dispozitive IoT, precum și distribuții Linux încorporate, cum ar fi OpenWRT și Embedded Gentoo.
Despre vulnerabilitate
Vulnerabilitate se datorează utilizării identificatorilor de tranzacție predictibili în cod pentru a trimite interogări de DNS. ID-ul de interogare DNS a fost ales prin simpla creștere a contorului fără randomizare suplimentară a numerelor de port, ceea ce a făcut posibilă otrăvirea cache-ului DNS prin trimiterea preventivă a pachetelor UDP cu răspunsuri false (răspunsul va fi acceptat dacă sosește înainte de răspunsul de la serverul real și include ID-ul corect).
Spre deosebire de metoda Kaminsky propusă în 2008, nu este nevoie să ghicim nici măcar ID-ul tranzacției, deoarece este inițial previzibil (inițial, valoarea este setată la 1, care crește cu fiecare cerere și nu este selectată aleatoriu).
Pentru a te proteja împotriva ghicirii ID-ului, specificației De asemenea, recomandă utilizarea unei distribuții aleatorii a numerelor de porturi de rețea de origine de la care sunt trimise interogări DNS, ceea ce compensează dimensiunea insuficientă a ID-ului.
Când randomizarea portului este activată, pentru a forma un răspuns fals, pe lângă selectarea unui identificator de 16 biți, este și necesar să selectați numărul portului de rețea. În uClibc și uClibc-ng, o astfel de randomizare nu a fost activată în mod explicit (când a fost apelată bind, nu a fost specificat un port UDP sursă aleatorie) și aplicarea sa depindea de configurația sistemului de operare.
Când randomizarea portului este dezactivată, determinarea ID-ului cererii de incrementat este marcată ca o sarcină banală. Dar chiar și în cazul randomizării, atacatorul trebuie doar să ghicească portul de rețea din intervalul 32768-60999, pentru care poate folosi trimiterea simultană masivă de răspunsuri false pe diferite porturi de rețea.
Problema a fost confirmat în toate versiunile actuale ale uClibc și uClibc-ng, inclusiv cele mai recente versiuni de uClibc 0.9.33.2 și uClibc-ng 1.0.40.
„Este important de reținut că o vulnerabilitate care afectează o bibliotecă standard C poate fi puțin complexă”, a scris echipa într-o postare pe blog în această săptămână.
„Nu numai că ar exista sute sau mii de apeluri către funcția vulnerabilă în mai multe puncte dintr-un singur program, dar vulnerabilitatea ar afecta un număr nedefinit de alte programe multi-furnizor configurate pentru a utiliza acea bibliotecă.”
În septembrie 2021, au fost transmise informații despre vulnerabilitate către CERT/CC pentru pregătirea coordonată a aranjamentelor. În ianuarie 2022, problema a fost împărtășită cu peste 200 de producători asociat cu CERT/CC.
În martie, a existat o încercare separată de a contacta întreținătorul proiectului uClibc-ng, dar acesta a răspuns că nu poate remedia el însuși vulnerabilitatea și a recomandat dezvăluirea publică a informațiilor despre problemă, în speranța de a obține ajutor pentru a dezvolta o remediere a comunității. . De la producători, NETGEAR a anunțat lansarea unei actualizări cu eliminarea vulnerabilității.
Este important de reținut că o vulnerabilitate care afectează o bibliotecă standard C poate fi puțin complexă. Nu numai că ar exista sute sau mii de apeluri către funcția vulnerabilă în mai multe puncte dintr-un singur program, dar vulnerabilitatea ar afecta un număr nedefinit de alte programe multi-furnizor configurate să folosească acea bibliotecă.
Se observă că vulnerabilitatea se manifestă în dispozitivele de la mulți producători (de exemplu, uClibc este utilizat în firmware-ul Linksys, Netgear și Axis), dar, deoarece vulnerabilitatea rămâne nepattchizată în uClibc și uClibc-ng, informații detaliate despre dispozitive și anumiți producători ai căror produse există o problemă, până când acestea sunt dezvăluite.
În cele din urmă dacă sunteți interesat să aflați mai multe despre asta, puteți verifica detaliile În următorul link.