Mobiliosios operacinės sistemos Aurora (Open Mobile Platform kompanijos sukurtos Sailfish OS šakutės) kūrėjai pasidalijo atskleidžiančia istorija apie pašalinimą. () Glibc, kuris rodomas tik ARMv7 platformoje. Informacija apie pažeidžiamumą buvo atskleista dar gegužę, tačiau iki pastarųjų dienų pataisymai nebuvo prieinami, nepaisant to, kad pažeidžiamumas didelis pavojaus lygis ir yra veikiantis išnaudojimo prototipas, leidžiantis organizuoti kodo vykdymą apdorojant duomenis, suformatuotus tam tikru būdu funkcijose memcpy() ir memmove(). Paketo pataisymai и dar nebuvo išleisti, o pažeidžiamumas išlieka nepataisytas beveik du mėnesius nuo viešo atskleidimo momento ir penkis mėnesius nuo to momento, kai buvo pranešta Glibc kūrėjams.
Pažeidžiamumas pasireiškė įdiegus memcpy() ir memmove() asamblėjos kalba, skirtas ARMv7, ir jį sukėlė neteisingas neigiamų parametro, lemiančio nukopijuojamos srities dydį, reikšmių apdorojimas. Problemos su pleistrų kūrimu prasidėjo, kai įmonės и paskelbė, kad jų platformoms problema nedaro įtakos, nes jos nekuria 32 bitų ARMv7 sistemoms ir nedalyvavo kuriant pataisą. Atrodo, kad daugelio įterptųjų platinimų kūrėjai pasitikėjo „Glibc“ komanda ir taip pat aktyviai nedalyvavo rengiant pataisą.
Pasirinkimas Siekdama užblokuoti problemą, „Huawei“ beveik iš karto pasiūlė pabandyti pakeisti surinkimo instrukcijas, veikiančias su pasirašytais operandais (bge ir blt), nepasirašytais analogais (blo ir bhs). „Glibc“ prižiūrėtojai sukūrė testų rinkinį, skirtą įvairioms klaidų sąlygoms patikrinti, po kurių paaiškėjo, kad „Huawei“ pataisas netinkamas ir neapdoroja visų įmanomų įvesties duomenų kombinacijų.
Kadangi Aurora OS turi 32 bitų ARM versiją, jos kūrėjai nusprendė patys pašalinti pažeidžiamumą ir pasiūlyti sprendimą bendruomenei. Sunkumas buvo tas, kad reikėjo parašyti veiksmingą funkcijos diegimą asamblėjos kalba ir atsižvelgti į įvairias įvesties argumentų parinktis. Diegimas buvo perrašytas naudojant nepasirašytas instrukcijas. Paaiškėjo, kad jis mažas, tačiau pagrindinė problema buvo išlaikyti vykdymo greitį ir išvengti „memcpy“ ir „memmove“ funkcijų našumo pablogėjimo, išlaikant suderinamumą su visais įvesties reikšmių deriniais.
Birželio pradžioje buvo parengtos dvi pataisos versijos, kurios įveikė Glibc prižiūrėtojų testavimo sistemą ir vidinį Aurora testų rinkinį. Birželio 3 dieną buvo pasirinktas vienas iš variantų ir į Glibc adresų sąrašą. Po savaitės
buvo dar viena panašaus požiūrio pataisa, kuri ištaisė daugialypės terpės diegimo problemą, kurią „Huawei“ anksčiau bandė išspręsti. Testavimas truko mėnesį ir dėl pleistro svarbos.
liepos 8 pataisymai į pagrindinę būsimo glibc 2.32 leidimo šaką. Diegimas apima du pataisas − daugialypiam memcpy diegimui ARMv7 ir skirtas memcpy() ir memmove() ARM diegimui bendrosios surinkimo kalbos.
Problema paliečia milijonus ARMv7 įrenginių, kuriuose veikia „Linux“, ir be atitinkamo atnaujinimo savininkams kyla pavojus, kai juos prijungia prie tinklo (gali būti užpultos tinkle pasiekiamos paslaugos ir programos, priimančios įvesties duomenis be dydžio apribojimų). Pavyzdžiui, pažeidžiamumą identifikavusių mokslininkų parengtas išnaudojimas parodo, kaip atakuoti automobilio informacinėje sistemoje įmontuotą HTTP serverį siunčiant labai didelę GET užklausą ir gauti root prieigą prie sistemos.
Šaltinis: opennet.ru