Security Researchers at Cisco details () in the Glibc implementation of the memcpy() function for the 32-bit ARMv7 platform. The problem is caused by incorrect handling of negative values ββof the parameter that determines the size of the copied area, due to the use of assembler optimizations that manipulate signed 32-bit integers. Calling memcpy() on ARMv7 systems with a negative size results in an incorrect comparison of values ββand an entry in an area outside the bounds of the specified buffer.
The vulnerability can be exploited to execute code in a situation where an attacker can organize the formation of a negative value of the variable through which the size of the copied data is passed (for example, a minus value will occur when transferring more than 2 GB of data, but during the attack, to go beyond the buffer, you need to pass at least 4GB). The memcpy() function is heavily used in applications, and ARMv7 processors are common in automotive systems, mobile, industrial, consumer, communication and embedded devices, which can potentially become targets of attacks using Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi. Fi and other external data sources (for example, network-accessible services and applications that accept input data with no size limit can be attacked).
An example is the creation of a working exploit to attack an http server built into automotive information systems, accessible via a car Wi-Fi network. A rogue attacker could exploit a vulnerability in memcpy on a given server by sending a very large GET request and gaining root access to the system.
On 32-bit x86 systems, the problem does not appear, since the implementation of memcpy for this architecture correctly interprets the variable with size as an unsigned integer value with type size_t (in assembly language for ARMv7 it is treated as a signed integer instead of size_t). The fix is ββcurrently available as , which will be part of the August Glibc 2.32 update.
The fix comes down to replacing the use of assembler instructions that operate on signed operands (bge and blt) with unsigned counterparts (blo and bhs).
The problem has not yet been fixed in (does not appear in Debian 8), , , OpenEmbedded, Tizen (used by glibc). ΠΈ the issue is not affected as they do not support 32-bit ARMv7 systems. Android is not vulnerable as it uses its own implementation of libc (Bionic). IN Musl is used by default in most builds, but glibc is also available in the repository.
Source: opennet.ru