Pesquisadores de segurança da Cisco detalhes () na implementação da função memcpy() fornecida na Glibc para a plataforma ARMv7 de 32 bits. O problema é causado pelo tratamento inadequado de valores negativos do parâmetro que define o tamanho da área a ser copiada, devido ao uso de otimizações em assembly que manipulam inteiros de 32 bits com sinal. A chamada memcpy() em sistemas ARMv7 com tamanho negativo resulta em comparações incorretas e gravações fora dos limites do buffer especificado.
A vulnerabilidade pode ser explorada para executar código em situações em que um invasor possa induzir a formação de um valor negativo para a variável que determina o tamanho dos dados copiados (por exemplo, um número negativo pode ocorrer ao transferir mais de 2 GB de dados, mas para a exploração, é necessário enviar pelo menos 4 GB para ultrapassar os limites do buffer). A função memcpy() é amplamente utilizada em aplicações, e os processadores ARMv7 são comuns em sistemas automotivos, dispositivos móveis, industriais, de consumo, de comunicação e embarcados, que podem potencialmente ser alvos de ataques através de Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi e outras fontes de dados externas (por exemplo, serviços e aplicações acessíveis pela rede que aceitam dados sem restrição de tamanho podem ser atacadas).
Como exemplo, é apresentado o desenvolvimento de um exploit funcional para atacar um servidor http incorporado nos sistemas de informação automotivos, acessível através da rede Wi-Fi do veículo. Um invasor externo pode explorar a vulnerabilidade na função memcpy deste servidor enviando uma solicitação GET de tamanho muito grande e obter acesso root ao sistema.
Em sistemas x86 de 32 bits, o problema não se manifesta, pois a implementação da memcpy para esta arquitetura interpreta corretamente a variável de tamanho como um valor inteiro sem sinal do tipo size_t (na escrita em assembly, para ARMv7 é tratado como inteiro com sinal). A correção está disponível no formato , que fará parte da atualização de agosto da Glibc 2.32.
A correção consiste em substituir o uso de instruções assembly que operam com operandos com sinal (bge e blt) por suas equivalentes sem sinal (blo e bhs).
O problema ainda não foi resolvido em (não se manifesta no Debian 8), , , OpenEmbedded, Tizen (utiliza glibc). e o problema não se aplica, uma vez que eles não suportam sistemas ARMv7 de 32 bits. O Android não é vulnerável, pois utiliza sua própria implementação da libc (Bionic). Em a maioria das compilações utiliza Musl por padrão, mas o repositório também contém glibc.
Fonte: opennet.ru
