The developers of the Aurora mobile operating system (a fork of the Sailfish OS developed by the Open Mobile Platform) shared a revealing story about eliminating () in Glibc, which only appears on the ARMv7 platform. Information about the vulnerability was disclosed back in May, but until the last days the fixes were not available, despite the fact that the vulnerabilities a high level of danger and there is a working exploit prototype that allows organizing code execution when processing data in a certain way in the memcpy () and memmove () functions. Package fixes for и not yet released and the vulnerability remains unpatched for almost two months from the date of public disclosure and five months from the notification of the Glibc developers.
The vulnerability manifested itself in the implementation of memcpy() and memmove() in assembly language for ARMv7 and was caused by incorrect handling of negative values of the parameter that determines the size of the copied area. Problems with patch development began when companies и announced that their platforms are not affected, as they do not build builds for 32-bit ARMv7 systems, and did not participate in the creation of the fix. The developers of many embedded distributions seem to have relied on the Glibc team, and also did not actively participate in the preparation of the fix.
Option to block the problem almost immediately proposed by Huawei, which tried to replace assembly instructions that operate on signed operands (bge and blt) with unsigned counterparts (blo and bhs). The maintainers of Glibc developed a set of tests to check for various error conditions, after which it turned out that the Huawei patch did not fit and did not handle all possible combinations of input data.
Since the Aurora OS has a 32-bit assembly for ARM, its developers decided to close the vulnerability on their own and offer a solution to the community. The difficulty was that it was necessary to write an efficient assembler implementation of the function and take into account various options for input arguments. The implementation has been rewritten to use unsigned instructions. turned out to be small, but the main problem was to maintain the speed of execution and avoid performance degradation of the memcpy and memmove functions, while maintaining compatibility with all combinations of input values.
In early June, two patches were prepared, passing the Glibc test maintainer framework and the Aurora internal test suite. On June 3, one of the options was chosen and to the Glibc mailing list. A week later
was another similar patch that fixed a problem in the multiarch implementation that Huawei had previously tried to fix. It took a month to test and in view of the importance of the patch.
July 8 fixes to the upstream release of glibc 2.32. The implementation includes two patches − for multiarch implementation of memcpy for ARMv7, and for a common assembler implementation of memcpy() and memmove() for ARM.
The problem affects millions of ARMv7 devices running Linux, and without an appropriate update, owners are at risk by connecting them to the network (services available over the network and applications that accept input data without size limits can be attacked). For example, in an exploit prepared by the researchers who discovered the vulnerability, it is shown how to attack the http server built into the automotive information system by transmitting a very large GET request and gain root access to the system.
Source: opennet.ru