AuroraOS-mobiilikäyttöjärjestelmän kehittäjät (Open Mobile Platform -yhtiön kehittämä Sailfish-käyttöjärjestelmän haarukka) jakoi haavoittuvuuden korjauksen jonka he havaitsivat memcpy: stä. Kriittisen haavoittuvuuden poistaminen (CVE-2020-6096) Glibcissä, joka ilmenee vain ARMv7-alustalla.
Tietoja haavoittuvuudesta paljastettiin toukokuussa, mutta viime päiviin asti korjaukset eivät olleet käytettävissä huolimatta siitä, että haavoittuvuudelle oli annettu suuri vaaran taso ja hyödyntämisestä on toimiva prototyyppi jonka avulla voidaan organisoida koodin suorittaminen.
Hyödyntäminen valmistautunut toimii prosessoinnin aikana memcpy () - ja memmove () -funktioissa tietyille alustetuille tiedoille.
Glibc: n merkitys on, että tämä kirjasto määrittelee järjestelmäkutsut ja muut perustoiminnot sen lisäksi, että lähes kaikki ohjelmat käyttävät sitä.
Tietoja ongelmasta
Haavoittuvuus ilmeni memcpy (): n ja memmove: n () toteutuksessa kokoonpanokielellä ARMv7: lle ja se johtui alueen koon määrittävän parametrin negatiivisten arvojen virheellisestä käsittelystä.
Laastarin kehittämisongelmat alkoivat kun SUSE ja Red Hat ilmoittivat, että heidän alustoihinsa ei vaikuteta ongelman takia, koska ne eivät kääntäneet 7-bittisiä ARMv32-järjestelmiä eivätkä osallistuneet korjaustiedoston luomiseen.
Monien sulautettujen jakelujen kehittäjät ilmeisesti luottivat Glibc-tiimiin, eivätkä he myöskään osallistuneet aktiivisesti korjaustiedoston valmisteluun.
ratkaisut
Huawei tarjosi vaihtoehdon laastaria varten estää ongelma melkein välittömästi, joka yritti korvata allekirjoitetuilla operandeilla (bge ja blt) toimivat kokoonpanijan ohjeet allekirjoittamattomilla analogeilla (blo ja bhs).
Glibc-ylläpitäjät kehittivät testipaketin testata erilaisia ehtoja virheen esiintymiselle jälkeen mikä osoitti, että Huawei-korjaustiedosto ei sovi eikä se käsittele kaikkia mahdollisia syötetietojen yhdistelmiä.
Dado que AuroraOSilla on 32-bittinen ARM-koontiversio, sen kehittäjät päättivät sulkea haavoittuvuuden yksin ja ehdottaa ratkaisua yhteisölle.
Vaikeus oli, että oli tarpeen kirjoittaa tehokas toteutus kokoonpanon ja harkitse useita vaihtoehtoja syöteargumenteille.
Toteutus on kirjoitettu uudelleen allekirjoittamattomilla ohjeilla. Korjaus osoittautui pieneksi, mutta pääongelmana oli suorituksen nopeuden ylläpitäminen ja suorituskyvyn heikkenemisen poistaminen memcpy- ja memmove-funktioista samalla, kun ylläpidettiin yhteensopivuutta kaikkien tuloarvojen yhdistelmien kanssa.
Kesäkuun alussa valmisteltiin kaksi ratkaisua, läpäissyt Glibcin huoltotestikehyksen ja Auroran sisäisen testipaketin. Yksi vaihtoehdoista valittiin ja lähetettiin 3. kesäkuuta Glibc-postituslistalle.
Viikkoa myöhemmin ehdotettiin toista samanlaista lähestymistapaa, joka korjasi ongelman moniarkkitoteutuksessa, jonka Huawei oli aiemmin yrittänyt korjata. Kuukausi kesti testausta ja laillistamista korjaustiedoston merkityksen vuoksi.
8. heinäkuuta korjaukset hyväksyttiin päähaarassa tulevasta glibc 2.32 -julkaisusta. Sovellus sisältää kaksi korjaustiedostoa:
- Ensimmäinen ARMv7: n muistinmuodostuksen Multiarch-sovellukselle
- Toinen on memcpy (): n ja memmove (): n ARM: n yhteisen kokoonpanijan toteuttamiseen.
Ongelma vaikuttaa miljooniin ARMv7 Linux -laitteisiin ja ilman asianmukaista päivitystä omistajat voivat liittää heidät verkkoon (voidaan hyökätä verkon palveluihin ja sovelluksiin, jotka hyväksyvät syötteen ilman kokorajoituksia).
Esimerkiksi valmis hyödyntäminen tutkijat, jotka löysi haavoittuvuuden näyttää kuinka hyökätä http-palvelimeen integroitu auton tietojärjestelmään lähettämällä erittäin suuri GET-pyyntö ja saamalla pääkäyttäjä järjestelmään.
Debianin ja Ubuntun pakettiratkaisuja ei ole vielä julkaistu y haavoittuvuus on edelleen korjaamaton lähes kahden kuukauden ajan julkistamisesta ja viiden kuukauden ajan siitä, kun Glibc-kehittäjille ilmoitettiin.