Glibc obsahuje opravu zranitelnosti memcpy připravenou vývojáři Aurora OS

Vývojáři mobilního operačního systému Aurora (fork OS Sailfish vyvinutý společností Open Mobile Platform) se podělili o odhalující příběh o odstranění kritická zranitelnost (CVE-2020-6096) v Glibc, který se objevuje pouze na platformě ARMv7. Informace o zranitelnosti byly zveřejněny již v květnu, ale až do posledních dnů nebyly k dispozici opravy, a to navzdory skutečnosti, že zranitelnosti přiděleno vysoká úroveň nebezpečí a existuje funkční prototyp exploitu, který vám umožňuje organizovat provádění kódu při zpracování dat naformátovaných určitým způsobem ve funkcích memcpy() a memmove(). Opravy balíčku pro Debian и ubuntu dosud nebyly vydány a zranitelnost zůstává neopravena téměř dva měsíce od okamžiku zveřejnění a pět měsíců od okamžiku, kdy byli vývojáři Glibc upozorněni.

Zranitelnost se projevila při implementaci memcpy() a memmove() v assembleru pro ARMv7 a byla způsobena nesprávným zpracováním záporných hodnot parametru, který určuje velikost kopírované oblasti. Problémy s vývojem patchů začaly, když společnosti SUSE и Red Hat oznámili, že jejich platformy nejsou tímto problémem ovlivněny, protože nevytvářejí pro 32bitové systémy ARMv7 a nepodílely se na vytváření opravy. Zdá se, že vývojáři mnoha embedded distribucí spoléhali na tým Glibc a také se aktivně nepodíleli na přípravě opravy.

Možnost náplast Aby Huawei problém zablokoval, téměř okamžitě navrhl, že se pokusí nahradit montážní instrukce pracující s podepsanými operandy (bge a blt) nepodepsanými analogy (blo a bhs). Správci Glibc vyvinuli sadu testů pro kontrolu různých chybových stavů, po kterých se ukázalo, že záplata Huawei není vhodná a nezpracovala všechny možné kombinace vstupních dat.

Vzhledem k tomu, že Aurora OS má 32bitové sestavení pro ARM, rozhodli se jeho vývojáři sami uzavřít zranitelnost a nabídnout řešení komunitě. Potíž byla v tom, že bylo nutné napsat efektivní implementaci funkce v assembleru a vzít v úvahu různé možnosti pro vstupní argumenty. Implementace byla přepsána pomocí nepodepsaných instrukcí. Náplast Ukázalo se, že je to malé, ale hlavním problémem bylo udržet rychlost provádění a vyhnout se snížení výkonu funkcí memcpy a memmove při zachování kompatibility se všemi kombinacemi vstupních hodnot.

Na začátku června byly připraveny dvě verze opravy, které prošly testovacím rámcem správců Glibc a interní testovací sadou Aurora. 3. června byla vybrána jedna z možností a odesláno do mailing listu Glibc. O týden později
byl navržený další patch podobného přístupu, který opravoval problém v implementaci multiarch, který se Huawei již dříve snažil opravit. Testování trvalo měsíc a legální registrace kvůli důležitosti náplasti.
opravy 8. července byly přijaty do hlavní větve nadcházejícího vydání glibc 2.32. Implementace obsahuje dvě záplaty − první pro multiarch implementaci memcpy pro ARMv7 a druhý pro implementaci memcpy() a memmove() pro ARM v obecném assembleru.

Problém se týká milionů zařízení ARMv7 s Linuxem a bez příslušné aktualizace jsou majitelé ohroženi při jejich připojení k síti (může dojít k napadení síťově přístupných služeb a aplikací, které přijímají vstupní data bez omezení velikosti). Například exploit připravený výzkumníky, kteří identifikovali zranitelnost, ukazuje, jak zaútočit na HTTP server zabudovaný do informačního systému automobilu odesláním velmi rozsáhlého požadavku GET a získat root přístup k systému.

Zdroj: opennet.ru

Přidat komentář