Os desenvolvedores do sistema operativo móbil Aurora (unha bifurcación do SO Sailfish desenvolvido pola compañía Open Mobile Platform) compartiron unha historia reveladora sobre a eliminación () en Glibc, que só aparece na plataforma ARMv7. A información sobre a vulnerabilidade revelouse en maio, pero ata os últimos días non se dispoñían de correccións, a pesar de que as vulnerabilidades un alto nivel de perigo e existe un prototipo funcional dun exploit que permite organizar a execución do código ao procesar datos formateados dun xeito determinado nas funcións memcpy() e memmove(). Correccións de paquetes para и aínda non se publicaron e a vulnerabilidade permanece sen solucionar durante case dous meses desde o momento da divulgación pública e cinco meses desde o momento en que os desenvolvedores de Glibc foron notificados.
A vulnerabilidade manifestouse na implementación de memcpy() e memmove() en linguaxe ensamblador para ARMv7 e foi causada polo procesamento incorrecto de valores negativos do parámetro que determina o tamaño da área copiada. Os problemas co desenvolvemento de parches comezaron cando as empresas и anunciaron que as súas plataformas non se ven afectadas polo problema, xa que non se constrúen para sistemas ARMv32 de 7 bits e non participaron na creación dunha corrección. Os desenvolvedores de moitas distribucións integradas parecen confiar no equipo de Glibc e tampouco participaron activamente na preparación da corrección.
Opción Para bloquear o problema, Huawei propuxo case inmediatamente que tentase substituír as instrucións de montaxe que operaban con operandos asinados (bge e blt) por análogos sen asinar (blo e bhs). Os mantedores de Glibc desenvolveron un conxunto de probas para comprobar varias condicións de erro, despois de que resultou que o parche de Huawei non era axeitado e non procesaba todas as combinacións posibles de datos de entrada.
Dado que Aurora OS ten unha compilación de 32 bits para ARM, os seus desenvolvedores decidiron pechar a vulnerabilidade por si mesmos e ofrecer unha solución á comunidade. A dificultade foi que era necesario escribir unha implementación eficiente da función en linguaxe ensamblador e ter en conta varias opcións para os argumentos de entrada. A implementación foi reescrita usando instrucións sen asinar. Resultou ser pequeno, pero o principal problema foi manter a velocidade de execución e evitar a degradación do rendemento das funcións memcpy e memmove, mantendo a compatibilidade con todas as combinacións de valores de entrada.
A principios de xuño preparáronse dúas versións da corrección, superando o marco de proba dos mantedores de Glibc e a suite de probas internas de Aurora. O 3 de xuño escolleuse unha das opcións e á lista de correo Glibc. Unha semana despois
foi outro parche similar no enfoque, que corrixiu un problema na implementación multiarch, que Huawei intentara solucionar previamente. As probas levaron un mes e pola importancia do parche.
Correccións do 8 de xullo á rama principal da próxima versión glibc 2.32. A implementación inclúe dous parches − para a implementación multiarch de memcpy para ARMv7 e para a implementación da linguaxe de montaxe xeral de memcpy() e memmove() para ARM.
O problema afecta a millóns de dispositivos ARMv7 que executan Linux e, sen a actualización axeitada, os propietarios corren un risco ao conectalos á rede (poden ser atacados os servizos accesibles na rede e as aplicacións que aceptan datos de entrada sen restricións de tamaño). Por exemplo, o exploit preparado polos investigadores que identificaron a vulnerabilidade mostra como atacar un servidor HTTP integrado nun sistema de información do coche enviando unha solicitude GET moi grande e obter acceso root ao sistema.
Fonte: opennet.ru