Glibc vključuje popravek za ranljivost memcpy, ki so ga pripravili razvijalci OS Aurora

Razvijalci mobilnega operacijskega sistema Aurora (razcep operacijskega sistema Sailfish OS, ki ga je razvilo podjetje Open Mobile Platform) so delili zanimivo zgodbo o odpravi kritična ranljivost (CVE-2020-6096) v Glibc, ki se pojavi samo na platformi ARMv7. Podatki o ranljivosti so bili razkriti že maja, a do zadnjih dni popravki niso bili na voljo, kljub temu, da so ranljivosti dodeljena visoka stopnja nevarnosti in obstaja delujoč prototip izkoriščanja, ki vam omogoča organiziranje izvajanja kode pri obdelavi podatkov, oblikovanih na določen način v funkcijah memcpy() in memmove(). Popravki paketa za Debian и Ubuntu še niso bile objavljene in ranljivost ostaja nepopravljena skoraj dva meseca od trenutka javnega razkritja in pet mesecev od trenutka, ko so bili razvijalci Glibc obveščeni.

Ranljivost se je pokazala pri implementaciji memcpy() in memmove() v zbirnem jeziku za ARMv7 in je nastala zaradi nepravilne obdelave negativnih vrednosti parametra, ki določa velikost kopiranega območja. Težave z razvojem popravkov so se začele, ko so podjetja SUSE и Red Hat sporočili, da težava ne vpliva na njihove platforme, ker ne gradijo za 32-bitne sisteme ARMv7, in niso sodelovali pri ustvarjanju popravka. Zdi se, da so se razvijalci številnih vgrajenih distribucij zanašali na ekipo Glibc in tudi niso bili aktivno vključeni v pripravo popravka.

Možnost obliž Da bi blokiral težavo, je Huawei skoraj takoj predlagal, da poskusi zamenjati navodila za sestavljanje, ki delujejo s podpisanimi operandi (bge in blt), z nepodpisanimi analogi (blo in bhs). Vzdrževalci Glibc so razvili nabor testov za preverjanje različnih stanj napak, nakar se je izkazalo, da Huaweijev popravek ni primeren in ne obdeluje vseh možnih kombinacij vhodnih podatkov.

Ker ima Aurora OS 32-bitno zgradbo za ARM, so se njeni razvijalci odločili, da sami zaprejo ranljivost in ponudijo rešitev skupnosti. Težava je bila v tem, da je bilo treba napisati učinkovito implementacijo funkcije v zbirnem jeziku in upoštevati različne možnosti vhodnih argumentov. Izvedba je bila prepisana z uporabo nepodpisanih navodil. Obliž Izkazalo se je, da je majhen, vendar je bila glavna težava ohranjanje hitrosti izvajanja in izogibanje poslabšanju zmogljivosti funkcij memcpy in memmove, hkrati pa ohranjanje združljivosti z vsemi kombinacijami vhodnih vrednosti.

V začetku junija sta bili pripravljeni dve različici popravka, ki sta prestali testno ogrodje vzdrževalcev Glibc in interni testni paket Aurora. 3. junija je bila izbrana ena od možnosti in poslano na poštni seznam Glibc. Teden dni kasneje
je bil predlagano še en popravek, podoben pristopu, ki je odpravil težavo v izvedbi z več archi, ki jo je Huawei že poskušal odpraviti. Testiranje je trajalo en mesec in pravna registracija zaradi pomembnosti popravka.
8. julij popravki so bili sprejeti na glavno vejo prihajajoče izdaje glibc 2.32. Izvedba vključuje dva popravka − первый za multiarch implementacijo memcpy za ARMv7 in 2. za izvedbo splošnega zbirnega jezika memcpy() in memmove() za ARM.

Težava zadeva milijone naprav ARMv7, ki poganjajo Linux, brez ustrezne posodobitve pa so lastniki ogroženi pri povezovanju v omrežje (napadene so lahko omrežno dostopne storitve in aplikacije, ki sprejemajo vhodne podatke brez velikostnih omejitev). Na primer, izkoriščanje, ki so ga pripravili raziskovalci, ki so odkrili ranljivost, prikazuje, kako napasti strežnik HTTP, vgrajen v avtomobilski informacijski sistem, s pošiljanjem zelo velike zahteve GET in pridobiti korenski dostop do sistema.

Vir: opennet.ru

Dodaj komentar