Os desenvolvedores do sistema operacional móvel Aurora (um fork do Sailfish OS desenvolvido pela empresa Open Mobile Platform) compartilharam uma história reveladora sobre a eliminação () no Glibc, que aparece apenas na plataforma ARMv7. As informações sobre a vulnerabilidade foram divulgadas em maio, mas até os últimos dias as correções não estavam disponíveis, apesar de as vulnerabilidades um alto nível de perigo e há um protótipo funcional de exploração que permite organizar a execução do código ao processar dados formatados de uma determinada maneira nas funções memcpy() e memmove(). Correções de pacotes para и ainda não foram liberados e a vulnerabilidade permanece sem correção por quase dois meses a partir do momento da divulgação pública e cinco meses a partir do momento em que os desenvolvedores do Glibc foram notificados.
A vulnerabilidade se manifestou na implementação de memcpy() e memmove() em linguagem assembly para ARMv7 e foi causada pelo processamento incorreto de valores negativos do parâmetro que determina o tamanho da área copiada. Os problemas com o desenvolvimento de patches começaram quando as empresas и anunciaram que suas plataformas não são afetadas pelo problema, uma vez que não constroem para sistemas ARMv32 de 7 bits e não participaram da criação de uma correção. Os desenvolvedores de muitas distribuições embarcadas parecem ter confiado na equipe Glibc e também não estiveram ativamente envolvidos na preparação da correção.
Opção Para bloquear o problema, a Huawei propôs quase imediatamente que tentasse substituir as instruções de montagem operando com operandos assinados (bge e blt) por análogos não assinados (blo e bhs). Os mantenedores do Glibc desenvolveram um conjunto de testes para verificar várias condições de erro, após os quais descobriu-se que o patch da Huawei não era adequado e não processava todas as combinações possíveis de dados de entrada.
Como o Aurora OS tem uma versão de 32 bits para ARM, seus desenvolvedores decidiram fechar a vulnerabilidade por conta própria e oferecer uma solução para a comunidade. A dificuldade era que era necessário escrever uma implementação eficiente da função em linguagem assembly e levar em consideração várias opções para argumentos de entrada. A implementação foi reescrita usando instruções não assinadas. Acabou sendo pequeno, mas o principal problema era manter a velocidade de execução e evitar a degradação do desempenho das funções memcpy e memmove, ao mesmo tempo que mantinha a compatibilidade com todas as combinações de valores de entrada.
No início de junho, foram preparadas duas versões da correção, passando pelo framework de testes dos mantenedores do Glibc e pelo conjunto de testes interno do Aurora. No dia 3 de junho uma das opções foi escolhida e para a lista de discussão Glibc. Uma semana depois
era outro patch de abordagem semelhante, que corrigiu um problema na implementação multiarch, que a Huawei já havia tentado consertar. Os testes demoraram um mês e devido à importância do patch.
Correções de 8 de julho para o branch principal da próxima versão glibc 2.32. A implementação inclui dois patches - para a implementação multiarch de memcpy para ARMv7, e para a implementação em linguagem assembly geral de memcpy() e memmove() para ARM.
O problema afeta milhões de dispositivos ARMv7 rodando Linux e, sem a atualização adequada, os proprietários correm riscos ao conectá-los à rede (serviços acessíveis pela rede e aplicativos que aceitam dados de entrada sem restrições de tamanho podem ser atacados). Por exemplo, a exploração preparada pelos pesquisadores que identificaram a vulnerabilidade mostra como atacar um servidor HTTP embutido em um sistema de informações automotivas, enviando uma solicitação GET muito grande e obtendo acesso root ao sistema.
Fonte: opennet.ru