Glibc inniheldur lagfæringu fyrir memcpy varnarleysið sem Aurora OS forritararnir hafa útbúið

Hönnuðir Aurora farsímastýrikerfisins (gafl af Sailfish OS þróað af Open Mobile Platform fyrirtækinu) deildu afhjúpandi sögu um útrýmingu mikilvæg varnarleysi (CVE-2020-6096) í Glibc, sem birtist aðeins á ARMv7 pallinum. Upplýsingar um veikleikann voru birtar aftur í maí, en þar til á síðustu dögum voru lagfæringar ekki tiltækar, þrátt fyrir að veikleikarnir úthlutað mikið hættustig og það er starfandi frumgerð af hagnýtingu sem gerir þér kleift að skipuleggja keyrslu kóða þegar unnið er úr gögnum sem eru sniðin á ákveðinn hátt í memcpy() og memmove() aðgerðunum. Pakki lagfæringar fyrir Debian и ubuntu hafa ekki enn verið gefin út og varnarleysið er óbundið í næstum tvo mánuði frá því augnabliki opinberrar birtingar og fimm mánuði frá því augnabliki sem Glibc verktaki var tilkynnt.

Varnarleysið kom fram í innleiðingu memcpy() og memmove() á samsetningartungumáli fyrir ARMv7 og stafaði af rangri vinnslu á neikvæðum gildum færibreytunnar sem ákvarðar stærð afritaðs svæðis. Vandamál með þróun plástra hófust þegar fyrirtæki suse и Red Hat tilkynnti að pallar þeirra hafi ekki áhrif á vandamálið, þar sem þeir byggja ekki fyrir 32-bita ARMv7 kerfi, og tóku ekki þátt í að búa til lagfæringu. Hönnuðir margra innbyggðra dreifinga virðast hafa reitt sig á Glibc teymið og hafa heldur ekki tekið virkan þátt í að undirbúa lagfæringuna.

Valkostur plástur Til að koma í veg fyrir vandamálið lagði Huawei næstum strax til að það reyndi að skipta út samsetningarleiðbeiningum sem starfa með undirrituðum operöndum (bge og blt) fyrir óundirritaða hliðstæður (blo og bhs). Glibc viðhaldsaðilar þróuðu sett af prófum til að athuga ýmis villuskilyrði, eftir það kom í ljós að Huawei plásturinn hentaði ekki og vann ekki úr öllum mögulegum samsetningum inntaksgagna.

Þar sem Aurora OS er með 32 bita smíði fyrir ARM ákváðu verktaki þess að loka veikleikanum á eigin spýtur og bjóða upp á lausn fyrir samfélagið. Erfiðleikarnir voru að það var nauðsynlegt að skrifa skilvirka samsetningu tungumálaútfærslu á fallinu og taka tillit til ýmissa valkosta fyrir inntaksrök. Útfærslan hefur verið endurskrifuð með óundirrituðum leiðbeiningum. Plástur Það reyndist lítið, en aðalvandamálið var að viðhalda keyrsluhraða og forðast frammistöðurýrnun á memcpy og memmove aðgerðunum, en viðhalda samhæfni við allar samsetningar inntaksgilda.

Í byrjun júní voru útbúnar tvær útgáfur af lagfæringunni, sem stóðust prófunarramma Glibc viðhaldsaðilanna og innri prófunarpakkann Aurora. Þann 3. júní var valinn einn af kostunum og sent á Glibc póstlistann. Viku seinna
var lagt til annar plástur svipaður í nálgun, sem leiðrétti vandamál í multiarch útfærslunni, sem Huawei hafði áður reynt að laga. Próf tók mánuð og lögskráning vegna mikilvægis plástursins.
8. júlí leiðréttingar voru samþykktar að aðalútibúi væntanlegrar glibc 2.32 útgáfu. Útfærslan inniheldur tvo plástra - первый fyrir multiarch útfærslu á memcpy fyrir ARMv7, og annað fyrir almenna samkomumálsútfærslu á memcpy() og memmove() fyrir ARM.

Vandamálið hefur áhrif á milljónir ARMv7 tækja sem keyra Linux og án viðeigandi uppfærslu eru eigendur í hættu þegar þeir tengja þau við netið (hægt er að ráðast á netaðgengilegar þjónustur og forrit sem taka við inntaksgögnum án stærðartakmarkana). Til dæmis sýnir hagnýtingin sem rannsakendurnir sem greindu varnarleysið útbúið hvernig á að ráðast á HTTP netþjón sem er innbyggður í upplýsingakerfi bíla með því að senda mjög stóra GET beiðni og fá rótaraðgang að kerfinu.

Heimild: opennet.ru

Bæta við athugasemd