Els desenvolupadors del sistema operatiu mòbil Aurora (una bifurcació del sistema operatiu Sailfish desenvolupat per l'empresa Open Mobile Platform) van compartir una història reveladora sobre l'eliminació () a Glibc, que només apareix a la plataforma ARMv7. La informació sobre la vulnerabilitat es va revelar al maig, però fins fa dies no hi havia solucions disponibles, malgrat que les vulnerabilitats un alt nivell de perill i hi ha un prototip de funcionament d'explotació que permet organitzar l'execució del codi quan es processen dades formatades d'una determinada manera a les funcions memcpy() i memmove(). Correccions de paquets per и encara no s'han publicat i la vulnerabilitat roman sense solucionar durant gairebé dos mesos des del moment de la divulgació pública i cinc mesos des del moment en què els desenvolupadors de Glibc van ser notificats.
La vulnerabilitat es va manifestar en la implementació de memcpy() i memmove() en llenguatge assemblador per a ARMv7 i va ser causada per un processament incorrecte de valors negatius del paràmetre que determina la mida de l'àrea copiada. Els problemes amb el desenvolupament de pedaços van començar quan les empreses и va anunciar que les seves plataformes no es veuen afectades pel problema, ja que no es construeixen per a sistemes ARMv32 de 7 bits i no van participar en la creació d'una solució. Els desenvolupadors de moltes distribucions incrustades semblen haver confiat en l'equip de Glibc i tampoc no han participat activament en la preparació de la solució.
Opció Per bloquejar el problema, Huawei va proposar gairebé immediatament que intentés substituir les instruccions de muntatge que operaven amb operands signats (bge i blt) per anàlegs sense signar (blo i bhs). Els mantenedors de Glibc van desenvolupar un conjunt de proves per comprovar diverses condicions d'error, després de les quals va resultar que el pegat de Huawei no era adequat i no processava totes les combinacions possibles de dades d'entrada.
Com que Aurora OS té una compilació de 32 bits per a ARM, els seus desenvolupadors van decidir tancar la vulnerabilitat pel seu compte i oferir una solució a la comunitat. La dificultat era que calia escriure una implementació eficient del llenguatge assemblador de la funció i tenir en compte diverses opcions per als arguments d'entrada. La implementació s'ha reescrit amb instruccions sense signar. Va resultar ser petit, però el principal problema era mantenir la velocitat d'execució i evitar la degradació del rendiment de les funcions memcpy i memmove, tot mantenint la compatibilitat amb totes les combinacions de valors d'entrada.
A principis de juny, es van preparar dues versions de la correcció, superant el marc de proves dels mantenedors de Glibc i la suite de proves interna d'Aurora. El 3 de juny es va escollir una de les opcions i a la llista de correu de Glibc. Una setmana després
era un altre pegat similar en enfocament, que va corregir un problema en la implementació multiarch, que Huawei havia intentat solucionar anteriorment. Les proves van durar un mes i per la importància del pegat.
Correccions del 8 de juliol a la branca principal de la propera versió de glibc 2.32. La implementació inclou dos pedaços − per a la implementació multiarch de memcpy per a ARMv7, i per a la implementació del llenguatge d'assemblea general de memcpy() i memmove() per a ARM.
El problema afecta milions de dispositius ARMv7 amb Linux i, sense l'actualització adequada, els propietaris corren un risc quan els connecten a la xarxa (es poden atacar els serveis accessibles a la xarxa i les aplicacions que accepten dades d'entrada sense restriccions de mida). Per exemple, l'explotació preparada pels investigadors que van identificar la vulnerabilitat mostra com atacar un servidor HTTP integrat en un sistema d'informació del cotxe enviant una sol·licitud GET molt gran i obtenir accés root al sistema.
Font: opennet.ru