Glibc sisältää korjauksen memcpy-haavoittuvuuteen, jonka Aurora OS -kehittäjät ovat valmistaneet

Aurora-mobiilikäyttöjärjestelmän (Open Mobile Platform -yhtiön kehittämän Sailfish-käyttöjärjestelmän haarukka) kehittäjät jakoivat paljastavan tarinan poistamisesta. kriittinen haavoittuvuus (CVE-2020-6096) Glibcissä, joka näkyy vain ARMv7-alustalla. Tietoa haavoittuvuudesta julkistettiin jo toukokuussa, mutta viime päiviin asti korjauksia ei ollut saatavilla, vaikka haavoittuvuudet määrätty korkea vaarataso ja hyväksikäytöstä on toimiva prototyyppi, jonka avulla voit järjestää koodin suorittamisen, kun käsitellään tietyllä tavalla muotoiltuja tietoja memcpy()- ja memmove()-funktioissa. Paketin korjaukset Debian и Ubuntu ei ole vielä julkaistu, ja haavoittuvuus pysyy korjaamattomana lähes kaksi kuukautta julkistamisen jälkeen ja viisi kuukautta siitä, kun Glibc-kehittäjille ilmoitettiin.

Haavoittuvuus ilmeni memcpy()- ja memmove()-komentojen toteutuksessa ARMv7:n kokoonpanokielellä ja johtui kopioitavan alueen koon määrittävän parametrin negatiivisten arvojen virheellisestä käsittelystä. Ongelmat korjaustiedostojen kehittämisessä alkoivat, kun yritykset SUSE и Red Hat ilmoitti, että ongelma ei vaikuta heidän alustoihinsa, koska niitä ei rakenneta 32-bittisille ARMv7-järjestelmille, eivätkä ne osallistuneet korjauksen luomiseen. Monien sulautettujen jakelujen kehittäjät näyttävät luottaneen Glibc-tiimiin eivätkä ole myöskään olleet aktiivisesti mukana korjauksen valmistelussa.

vaihtoehto laastari Ongelman estämiseksi Huawei ehdotti lähes välittömästi, että se yritti korvata allekirjoitetuilla operandilla (bge ja blt) toimivat kokoonpanoohjeet etumerkittömillä analogeilla (blo ja bhs). Glibc-ylläpitäjät kehittivät joukon testejä erilaisten virheolosuhteiden tarkistamiseksi, minkä jälkeen kävi ilmi, että Huawei-korjaustiedosto ei ollut sopiva eikä käsitellyt kaikkia mahdollisia syötetietojen yhdistelmiä.

Koska Aurora OS:ssä on 32-bittinen versio ARM:lle, sen kehittäjät päättivät sulkea haavoittuvuuden itse ja tarjota ratkaisun yhteisölle. Vaikeutena oli se, että funktiosta piti kirjoittaa tehokas assembly-kielen toteutus ja ottaa huomioon erilaiset syöttöargumentit. Toteutus on kirjoitettu uudelleen allekirjoittamattomilla ohjeilla. Patch Se osoittautui pieneksi, mutta suurin ongelma oli suoritusnopeuden ylläpitäminen ja memcpy- ja memmove-toimintojen suorituskyvyn heikkenemisen välttäminen säilyttäen samalla yhteensopivuuden kaikkien syötearvojen yhdistelmien kanssa.

Korjauksesta valmisteltiin kesäkuun alussa kaksi versiota, jotka läpäisivät Glibc-ylläpitäjien testikehyksen ja Auroran sisäisen testipaketin. Kesäkuun 3. päivänä yksi vaihtoehdoista valittiin ja lähetetty Glibc-postituslistalle. Viikkoa myöhemmin
se oli ehdotettu toinen samanlainen korjaustiedosto, joka korjasi moniarkkitoteutuksen ongelman, jonka Huawei oli aiemmin yrittänyt korjata. Testaus kesti kuukauden ja laillinen rekisteröinti laastarin tärkeyden vuoksi.
8. heinäkuuta korjaukset hyväksyttiin tulevan glibc 2.32 -julkaisun päähaaraan. Toteutus sisältää kaksi korjaustiedostoa − первый memcpyn moniarkkitoteutukseen ARMv7:lle ja toinen memcpy()- ja memmove()-toteutuskielelle ARM:lle.

Ongelma koskee miljoonia Linuxia käyttäviä ARMv7-laitteita, ja ilman asianmukaista päivitystä omistajat ovat vaarassa kytkeä niitä verkkoon (verkkoon käytettäviin palveluihin ja sovelluksiin, jotka hyväksyvät syötetiedot ilman kokorajoituksia, voidaan hyökätä). Esimerkiksi haavoittuvuuden tunnistaneiden tutkijoiden valmistelema hyväksikäyttö osoittaa, kuinka hyökätään auton tietojärjestelmään sisäänrakennettua HTTP-palvelinta vastaan ​​lähettämällä erittäin suuri GET-pyyntö ja hankitaan pääkäyttäjän oikeudet järjestelmään.

Lähde: opennet.ru

Lisää kommentti