Pesquisadores de segurança da Cisco detalhes () na implementação da função memcpy() fornecida pela Glibc para a plataforma ARMv32 de 7 bits. O problema é causado pelo tratamento incorreto dos valores negativos do parâmetro que determina o tamanho da área copiada, devido ao uso de otimizações de montagem que manipulam inteiros assinados de 32 bits. Chamar memcpy() em sistemas ARMv7 com tamanho negativo resulta em comparação incorreta de valores e gravações em uma área fora dos limites do buffer especificado.
A vulnerabilidade pode ser explorada para executar código em uma situação em que o invasor possa organizar a formação de um valor negativo da variável através da qual o tamanho dos dados copiados é transmitido (por exemplo, ficará negativo ao transferir mais de 2 GB de dados, mas durante o ataque, para ultrapassar os limites do buffer, você precisa transferir pelo menos 4 GB). A função memcpy() é amplamente utilizada em aplicações, e os processadores ARMv7 são comuns em sistemas automotivos, móveis, industriais, de consumo, comunicações e dispositivos embarcados, que estão potencialmente sujeitos a ataques usando Bluetooth, HD Radio/DAB, USB, barramento CAN, Wi-Fi Fi e outras fontes de dados externas (por exemplo, serviços e aplicativos acessíveis pela rede que aceitam dados de entrada sem restrições de tamanho podem ser atacados).
Um exemplo é a criação de uma exploração funcional para atacar um servidor HTTP integrado em sistemas de informação automotiva, acessível através da rede Wi-Fi automotiva. Um invasor externo poderia explorar uma vulnerabilidade memcpy neste servidor enviando uma solicitação GET muito grande e obter acesso root ao sistema.
Em sistemas x32 de 86 bits, o problema não aparece, pois a implementação memcpy para esta arquitetura interpreta corretamente a variável size como um valor inteiro não assinado do tipo size_t (em linguagem assembly para ARMv7 é tratado como um número inteiro assinado em vez de size_t). A correção está atualmente disponível como , que será incluído na atualização 2.32 do Glibc de agosto.
A correção se resume a substituir o uso de instruções assembly que operam em operandos assinados (bge e blt) por contrapartes não assinadas (blo e bhs).
O problema ainda não foi resolvido (não visível no Debian 8), , , OpenEmbedded, Tizen (usado pela glibc). и O problema não é afetado porque eles não suportam sistemas ARMv32 de 7 bits. O Android não é afetado pela vulnerabilidade porque usa sua própria implementação libc (Bionic). EM Por padrão, a maioria das compilações usa Musl, mas glibc também está disponível no repositório.
Fonte: opennet.ru