Aurora OS developers included a memcpy fix in Glibc

Developers of the AuroraOS mobile operating system (a fork of the Sailfish operating system, developed by the Open Mobile Platform company) shared a fix for a vulnerability that they detected in memcpy. Elimination of critical vulnerability (CVE-2020-6096) in Glibc, which manifests itself only on the ARMv7 platform.

Information about the vulnerability was revealed in May, but until the last few days, the fixes were not available, despite the vulnerability being assigned a high level of danger and there is a working prototype of the exploit that allows to organize the execution of the code.

The exploit prepared acts during processing in memcpy () and memmove () functions for certain formatted data.

The importance of Glibc is that this library defines system calls and other basic functions in addition to being used by almost all programs.

About the problem

The vulnerability manifested in the implementation of memcpy () and memmove () in assembly language for ARMv7 and it was caused by incorrect processing of negative values ​​of the parameter that determines the size of the area.

Problems with patch development started when SUSE and Red Hat announced that their platforms were unaffected because of the problem, as they did not compile for 7-bit ARMv32 systems and did not participate in creating the patch.

The developers of many embedded distributions apparently trusted the Glibc team, and they also did not take an active part in preparing the patch.

Solutions

Huawei offered an option for a patch to block the problem almost immediately, which tried to replace assembler instructions that operate on signed operands (bge and blt) with unsigned analogs (blo and bhs).

Glibc maintainers developed a test suite to test different conditions for the occurrence of an error, after which turned out that Huawei's patch does not fit and it does not process all possible combinations of input data.

Given that AuroraOS has a 32-bit build for ARM, Its developers decided to close the vulnerability on their own and propose a solution to the community.

The difficulty was that, it was necessary to write an effective implementation assembler of the function and consider several options for the input arguments.

The implementation has been rewritten using unsigned instructions. The patch turned out to be small, but the main problem was maintaining execution speed and eliminating performance degradation from the memcpy and memmove functions, while maintaining compatibility with all combinations of input values.

At the beginning of June, two solutions were prepared, passing Glibc's maintenance test framework and Aurora's internal test suite. On June 3, one of the options was selected and submitted to the Glibc mailing list.

A week later, another similar approach was proposed, which fixed the problem in the multiarch implementation, which Huawei had previously tried to fix. A month took testing and legalization in view of the importance of the patch.

On July 8, fixes were accepted in the main branch of the upcoming glibc 2.32 release. The application includes two patches:

  • The first for a memory establishment Multiarch application for ARMv7
  • The second for a common assembler implementation of memcpy () and memmove () for ARM.

The problem affects millions of ARMv7 Linux devices and without a proper update, owners risk connecting them to the network (services and applications available on the network that accept input without size restrictions can be attacked).

For example, a prepared exploit by researchers who discovered the vulnerability shows how to attack an http server integrated into the car information system by transmitting a very large GET request and gaining root access to the system.

Package solutions for Debian and Ubuntu have not yet been released y vulnerability remains uncorrected for almost two months from the time of public disclosure and five months from the time the Glibc developers were notified.


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.