Az Aurora mobil operációs rendszer (az Open Mobile Platform cég által kifejlesztett Sailfish OS villája) fejlesztői megosztottak egy leleplező történetet a kiküszöbölésről. () a Glibc-ben, amely csak az ARMv7 platformon jelenik meg. A sérülékenységgel kapcsolatos információkat még májusban hoztak nyilvánosságra, de a napokig nem volt elérhető javítás, annak ellenére, hogy a sérülékenységek magas a veszély szintje, és létezik egy működő prototípus egy exploitnak, amely lehetővé teszi a kódvégrehajtás megszervezését a memcpy() és memmove() függvényekben meghatározott módon formázott adatok feldolgozásakor. Csomagjavítások a и még nem adták ki, és a sérülékenység a nyilvánosságra hozataltól számítva csaknem két hónapig, illetve a Glibc fejlesztőinek értesítésétől számított öt hónapig javítatlan marad.
A sérülékenység a memcpy() és a memmove() ARMv7 assembly nyelvű megvalósításában nyilvánult meg, és a másolt terület méretét meghatározó paraméter negatív értékeinek helytelen feldolgozása okozta. A javítások fejlesztésével kapcsolatos problémák akkor kezdődtek, amikor a vállalatok и bejelentette, hogy platformjaikat nem érinti a probléma, mivel nem 32 bites ARMv7 rendszerre építenek, és nem vettek részt a javítás létrehozásában. Úgy tűnik, hogy sok beágyazott disztribúció fejlesztői a Glibc csapatára támaszkodtak, és nem vettek részt aktívan a javítás előkészítésében.
opció A probléma kiküszöbölése érdekében a Huawei szinte azonnal azt javasolta, hogy megpróbálja az előjeles operandusokkal (bge és blt) működő összeszerelési utasításokat előjel nélküli analógokkal (blo és bhs) helyettesíteni. A Glibc karbantartói egy tesztsorozatot dolgoztak ki a különböző hibaállapotok ellenőrzésére, amelyek után kiderült, hogy a Huawei javítás nem megfelelő, és nem dolgozta fel a bemeneti adatok összes lehetséges kombinációját.
Mivel az Aurora OS 32 bites ARM-verzióval rendelkezik, a fejlesztők úgy döntöttek, hogy maguk zárják be a sebezhetőséget, és megoldást kínálnak a közösségnek. A nehézséget az jelentette, hogy a függvény hatékony assembly nyelvű implementációját kellett megírni, és figyelembe kellett venni a bemeneti argumentumok különböző lehetőségeit. A megvalósítás aláírás nélküli utasításokkal lett átírva. Kicsinek bizonyult, de a fő probléma a végrehajtási sebesség fenntartása és a memcpy és memmove funkciók teljesítményromlásának elkerülése volt, miközben a bemeneti értékek minden kombinációjával megőrizte a kompatibilitást.
Június elején elkészült a javítás két verziója, amelyek átmentek a Glibc karbantartók tesztkeretrendszerén és az Aurora belső tesztcsomagján. Június 3-án az egyik lehetőséget választották és a Glibc levelezőlistára. Egy héttel később
ez volt egy másik, hasonló megközelítésű javítás, amely kijavította a multiarch implementáció egyik hibáját, amelyet a Huawei korábban megpróbált kijavítani. A tesztelés egy hónapig tartott, és a tapasz fontossága miatt.
július 8-i korrekciók a közelgő glibc 2.32-es kiadás fő ágára. A megvalósítás két javítást tartalmaz − a memcpy multiarchív megvalósításához ARMv7-hez, és A memcpy() és memmove() általános összeállítás nyelvi megvalósításához ARM-hez.
A probléma több millió Linuxot futtató ARMv7-es eszközt érint, és megfelelő frissítés nélkül a tulajdonosok veszélybe kerülnek a hálózathoz való csatlakozáskor (megtámadhatók a hálózaton elérhető szolgáltatások és a bemeneti adatokat méretkorlátozás nélkül fogadó alkalmazások). A sérülékenységet azonosító kutatók által készített exploit például azt mutatja be, hogyan lehet megtámadni egy autóinformációs rendszerbe épített HTTP szervert egy nagyon nagy GET kérés elküldésével, és root hozzáférést szerezni a rendszerhez.
Forrás: opennet.ru