Cercetătorii de securitate Cisco detalii () în implementarea funcției memcpy() furnizată de Glibc pentru platforma ARMv32 pe 7 de biți. Problema este cauzată de manipularea incorectă a valorilor negative ale parametrului care determină dimensiunea zonei copiate, datorită utilizării optimizărilor de asamblare care manipulează numere întregi semnate pe 32 de biți. Apelarea memcpy() pe sistemele ARMv7 cu o dimensiune negativă are ca rezultat compararea incorectă a valorilor și scrierile într-o zonă în afara limitelor tamponului specificat.
Vulnerabilitatea poate fi exploatată pentru a executa cod într-o situație în care atacatorul poate organiza formarea unei valori negative a variabilei prin care se transmite dimensiunea datelor copiate (de exemplu, aceasta va deveni negativă la transferul a mai mult de 2 GB de date, dar în timpul atacului, pentru a depăși limitele buffer-ului, trebuie să transferați cel puțin 4 GB). Funcția memcpy() este utilizată pe scară largă în aplicații, iar procesoarele ARMv7 sunt comune în sistemele auto, dispozitivele mobile, industriale, de consum, de comunicații și încorporate, care pot fi supuse atacurilor prin Bluetooth, HD Radio/DAB, USB, magistrala CAN, Wi-Fi și alte surse de date externe (de exemplu, serviciile și aplicațiile accesibile prin rețea care acceptă date de intrare fără restricții de dimensiune pot fi atacate).
Un exemplu este crearea unui exploit de lucru pentru a ataca un server HTTP încorporat în sistemele de informații auto, accesibil prin rețeaua Wi-Fi a automobilului. Un atacator extern ar putea exploata o vulnerabilitate memcpy pe acest server prin trimiterea unei cereri GET foarte mare și să obțină acces root la sistem.
Pe sistemele x32 pe 86 de biți, problema nu apare, deoarece implementarea memcpy pentru această arhitectură interpretează corect variabila dimensiune ca o valoare întreagă fără semn de tip size_t (în limbajul de asamblare pentru ARMv7 este tratat ca un întreg cu semn în loc de size_t). Remedierea este disponibilă în prezent ca , care va fi inclus în actualizarea Glibc 2.32 din august.
Remedierea se rezumă la înlocuirea folosirii instrucțiunilor de asamblare care funcționează pe operanzi semnati (bge și blt) cu omologi nesemnați (blo și bhs).
Problema nu a fost încă rezolvată (nu este vizibil în Debian 8), , , OpenEmbedded, Tizen (utilizat de glibc). и Problema nu este afectată deoarece acestea nu acceptă sisteme ARMv32 pe 7 de biți. Android nu este afectat de vulnerabilitate deoarece folosește propria sa implementare libc (Bionic). ÎN În mod implicit, majoritatea versiunilor folosesc Musl, dar glibc este disponibil și în depozit.
Sursa: opennet.ru