Security researchers from Cisco details () in the implementation provided in the Glibc function memcpy() for the 32-bit ARMv7 platform. The issue is caused by incorrect handling of negative values for the parameter defining the size of the memory area to be copied, due to the use of assembler optimizations that manipulate signed 32-bit integers. Calling memcpy() on ARMv7 systems with a negative size leads to incorrect comparisons of values and writes outside the boundaries of the specified buffer.
The vulnerability can be exploited to execute code in situations where an attacker can manipulate the formation of a negative value for the variable through which the size of the data to be copied is passed (for example, going negative will occur when more than 2 GB of data is sent, but during the attack, to overflow the buffer, at least 4 GB must be transmitted). The memcpy() function is widely used in applications, and ARMv7 processors are prevalent in automotive systems, mobile, industrial, consumer, communication, and embedded devices, which could potentially become targets for attacks using Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi, and other external data sources (for example, network-accessible services and applications that accept input without size limitations could be attacked).
As an example, a working exploit is created for attacking the HTTP server embedded in automotive information systems, accessible via the car's Wi-Fi network. An external attacker can exploit the memcpy vulnerability on this server by sending a very large GET request and gain root access to the system.
On 32-bit x86 systems, the problem does not manifest, as the memcpy implementation for this architecture correctly interprets the size variable as an unsigned integer of type size_t (in assembler code, for ARMv7 instead of size_t it is processed as a signed integer). A fix is currently available in the form of , which will be included in the August update of Glibc 2.32.
The fix involves replacing the use of assembler instructions that operate on signed operands (bge and blt) with their unsigned counterparts (blo and bhs).
The issue has not yet been resolved in (it does not manifest in Debian 8), , , OpenEmbedded, Tizen (uses glibc). and the issue does not affect them, as they do not support 32-bit ARMv7 systems. Android is not susceptible to the vulnerability, as it uses its own implementation of libc (Bionic). In most builds Musl is used by default, but glibc is also available in the repository.
Source: opennet.ru
