Glibc uključuje popravak za ranjivost memcpy koji su pripremili programeri Aurora OS-a

Programeri mobilnog operativnog sustava Aurora (odvojak Sailfish OS-a koji je razvila tvrtka Open Mobile Platform) podijelili su zanimljivu priču o uklanjanju kritična ranjivost (CVE-2020-6096) u Glibcu, koji se pojavljuje samo na ARMv7 platformi. Informacija o ranjivosti objavljena je još u svibnju, ali sve do posljednjih dana popravci nisu bili dostupni, unatoč činjenici da su ranjivosti dodijeljen visoka razina opasnosti i postoji radni prototip eksploatacije koji vam omogućuje organiziranje izvršavanja koda prilikom obrade podataka formatiranih na određeni način u funkcijama memcpy() i memmove(). Popravci paketa za Debian и Ubuntu još nisu objavljeni i ranjivost ostaje neispravljena gotovo dva mjeseca od trenutka javnog objavljivanja i pet mjeseci od trenutka kada su programeri Glibca obaviješteni.

Ranjivost se očitovala u implementaciji memcpy() i memmove() u asemblerskom jeziku za ARMv7, a uzrokovana je pogrešnom obradom negativnih vrijednosti parametra koji određuje veličinu kopiranog područja. Problemi s razvojem zakrpa počeli su kada su tvrtke SUSE и Red Hat objavili su da problem ne utječe na njihove platforme, budući da ne grade za 32-bitne ARMv7 sustave, te nisu sudjelovali u izradi popravka. Čini se da su se programeri mnogih ugrađenih distribucija oslanjali na Glibc tim, a također nisu bili aktivno uključeni u pripremu popravka.

opcija zakrpa Kako bi blokirao problem, Huawei je gotovo odmah predložio da se pokušaju zamijeniti asemblerske instrukcije koje rade s potpisanim operandima (bge i blt) s nepredpisanim analozima (blo i bhs). Održavatelji Glibc-a razvili su set testova za provjeru različitih stanja grešaka, nakon čega se pokazalo da Huawei patch nije bio odgovarajući i da nije obradio sve moguće kombinacije ulaznih podataka.

Budući da Aurora OS ima 32-bitnu verziju za ARM, njeni programeri odlučili su sami zatvoriti ranjivost i ponuditi rješenje zajednici. Poteškoća je bila u tome što je bilo potrebno napisati učinkovitu implementaciju funkcije na asemblerskom jeziku i uzeti u obzir različite opcije za ulazne argumente. Implementacija je ponovno napisana pomoću nepotpisanih uputa. Zakrpa Ispostavilo se da je mali, ali glavni problem bio je održavanje brzine izvršenja i izbjegavanje degradacije performansi funkcija memcpy i memmove, uz održavanje kompatibilnosti sa svim kombinacijama ulaznih vrijednosti.

Početkom lipnja pripremljene su dvije verzije popravka koje su prošle testni okvir Glibc održavatelja i interni testni paket Aurore. Dana 3. lipnja odabrana je jedna od opcija i poslano na Glibc mailing listu. Tjedan poslije
to je bio zaprosio još jedna zakrpa sličnog pristupa, koja je ispravila problem u multiarch implementaciji, koji je Huawei prethodno pokušao popraviti. Testiranje je trajalo mjesec dana i zakonska registracija zbog važnosti zakrpe.
8. srpnja ispravci bili prihvaćeni u glavnu granu nadolazećeg izdanja glibc 2.32. Implementacija uključuje dvije zakrpe − первый za multiarch implementaciju memcpy za ARMv7, i drugi za implementaciju memcpy() i memmove() za opću asemblerski jezik za ARM.

Problem pogađa milijune ARMv7 uređaja koji rade na Linuxu, a bez odgovarajućeg ažuriranja vlasnici su u opasnosti prilikom povezivanja na mrežu (mrežno dostupni servisi i aplikacije koje prihvaćaju ulazne podatke bez ograničenja veličine mogu biti napadnuti). Na primjer, exploit koji su pripremili istraživači koji su identificirali ranjivost pokazuje kako napasti HTTP poslužitelj ugrađen u informacijski sustav automobila slanjem vrlo velikog GET zahtjeva i dobiti root pristup sustavu.

Izvor: opennet.ru

Dodajte komentar