Els desenvolupadors de sistema operatiu mòbil AuroraOS (Un fork de el sistema operatiu Sailfish, desenvolupat per la companyia Open Mobile Platform) van compartir una solució per a una vulnerabilitat que van detectar en memcpy. L'eliminació de la vulnerabilitat crítica (CVE-2020-6096) a Glibc, Que es manifesta només a la plataforma ARMv7.
La informació sobre la vulnerabilitat es va revelar al maig, Però fins als últims dies, les correccions no estaven disponibles, tot i que a la vulnerabilitat se li va assignar un alt nivell de perill i hi ha un prototip funcional de l'exploit que permet organitzar l'execució de el codi.
L'exploit preparat actua durant el processament en les funcions memcpy () i memmove () per certes dades amb format.
La importància de Glibc, és que aquesta biblioteca defineix les trucades a sistema i altres funcions bàsiques més que és utilitzada per gairebé tots els programes.
Sobre el problema
La vulnerabilitat es va manifestar en la implementació de memcpy () i memmove () en assemblador per ARMv7 i va ser causada pel processament incorrecte dels valors negatius de l'paràmetre que determina la mida de l'àrea.
Els problemes amb el desenvolupament de pegats van començar quan SUSE i Red Hat van anunciar que les seves plataformes no es van veure afectades pel problema, ja que no van formar compilacions per a sistemes ARMv7 de 32 bits i no van participar en la creació de l'pegat.
Els desenvolupadors de moltes distribucions incrustades aparentment van confiar en l'equip de Glibc, i tampoc van prendre part activa en la preparació de l'pegat.
Solucions
Huawei va oferir una opció per a un pegat per bloquejar el problema gairebé immediatament, que va tractar de reemplaçar les instruccions de l'ensamblador que operen a operands signats (BGE i BLT) amb anàlegs sense signar (bloc i BHS).
Els mantenidors d'Glibc van desenvolupar un conjunt de proves per a provar diferents condicions per a l'ocurrència d'un error, després de la qual cosa va resultar que el pegat d'Huawei no s'ajusta i no processa totes les combinacions possibles de dades d'entrada.
atès que AuroraOS té un recull de 32 bits per a ARM, els seus desenvolupadors van decidir tancar la vulnerabilitat pel seu compte i proposar una solució a la comunitat.
La dificultat era que, calia escriure una implementació efectiva d'assemblador de la funció i tenir en compte diverses opcions per als arguments d'entrada.
La implementació ha estat reescrita usant instruccions sense signar. El pegat va resultar ser petit, però el problema principal era mantenir la velocitat d'execució i eliminar la degradació de l'rendiment de les funcions memcpy i memmove, mantenint la compatibilitat amb totes les combinacions de valors d'entrada.
A principis de juny, es van preparar dues solucions, passant el marc de prova de manteniment de Glibc i el conjunt de proves internes d'Aurora. El 3 de juny, una de les opcions va ser seleccionada i enviada a la llista de correu de Glibc.
Una setmana després, es va proposar un altre enfocament similar, que va solucionar el problema en la implementació multiarch, que Huawei havia tractat de solucionar prèviament. Un mes va prendre proves i legalització en vista de la importància de l'pegat.
El 8 de juliol, es van acceptar correccions en la branca principal de el proper llançament de glibc 2.32. L'aplicació inclou dos pegats:
- La primera per a una aplicació Multiarch d'establiment de memòria per ARMv7
- El segon per a una implementació d'assemblador comuna de memcpy () i memmove () per a ARM.
El problema afecta milions de dispositius Linux ARMv7 i sense una actualització adequada, els propietaris s'arrisquen a connectar-los a la xarxa (els serveis i aplicacions disponibles a la xarxa que accepten entrades sense restriccions de mida poden ser atacats).
Per exemple, un exploit preparat per investigadors que van descobrir la vulnerabilitat mostra com atacar un servidor http integrat en el sistema d'informació de l'automòbil mitjançant la transmissió d'una sol·licitud GET molt gran i obtenir accés de root a el sistema.
Les solucions de paquets per a Debian i Ubuntu encara no s'ha publicat y la vulnerabilitat roman sense corregir durant gairebé dos mesos des del moment de la divulgació pública i cinc mesos des del moment en què es va notificar als desenvolupadors de Glibc.