Glibc включва корекция за уязвимостта memcpy, подготвена от разработчиците на Aurora OS

Разработчиците на мобилната операционна система Aurora (разклонение на Sailfish OS, разработена от компанията Open Mobile Platform) споделиха разкриваща история за премахване на критична уязвимост (CVE-2020 6096-) в Glibc, който се появява само на платформата ARMv7. Информацията за уязвимостта беше разкрита още през май, но до последните дни корекциите не бяха налични, въпреки факта, че уязвимостите възложено високо ниво на опасност и има работещ прототип на експлойта, който ви позволява да организирате изпълнението на код при обработка на данни, форматирани по определен начин във функциите memcpy() и memmove(). Корекции на пакети за Debian и Ubuntu все още не са пуснати и уязвимостта остава неотстранена почти два месеца от момента на публичното разкриване и пет месеца от момента, в който разработчиците на Glibc са били уведомени.

Уязвимостта се проявява при внедряването на memcpy() и memmove() в асемблерния език за ARMv7 и е причинена от неправилна обработка на отрицателни стойности на параметъра, който определя размера на копираната област. Проблемите с разработването на корекции започнаха, когато компаниите SUSE и Кардинал обяви, че техните платформи не са засегнати от проблема, тъй като те не изграждат за 32-битови ARMv7 системи и не са участвали в създаването на корекция. Разработчиците на много вградени дистрибуции изглежда са разчитали на екипа на Glibc и също така не са участвали активно в подготовката на корекцията.

опция пластир За да блокира проблема, Huawei почти веднага предложи да се опита да замени инструкциите за асемблиране, работещи със знакови операнди (bge и blt) с неподписани аналози (blo и bhs). Поддържащите Glibc разработиха набор от тестове за проверка на различни състояния на грешка, след което се оказа, че корекцията на Huawei не е подходяща и не обработва всички възможни комбинации от входни данни.

Тъй като Aurora OS има 32-битова версия за ARM, нейните разработчици решиха сами да затворят уязвимостта и да предложат решение на общността. Трудността беше, че беше необходимо да се напише ефективна реализация на функцията на асемблер и да се вземат предвид различни опции за входни аргументи. Изпълнението е пренаписано с помощта на неподписани инструкции. кръпка Оказа се, че е малък, но основният проблем беше поддържането на скоростта на изпълнение и избягването на влошаване на производителността на функциите memcpy и memmove, като същевременно се поддържа съвместимост с всички комбинации от входни стойности.

В началото на юни бяха подготвени две версии на корекцията, преминали тестовия фреймуърк на поддържащите Glibc и вътрешния тестов пакет на Aurora. На 3 юни беше избран един от вариантите и изпратен към пощенския списък на Glibc. Седмица по-късно
Това беше предложено друга корекция, подобна на подхода, която коригира проблем в реализацията на мултиарх, който Huawei преди това се опита да коригира. Тестването отне месец и правна регистрация поради важността на пластира.
Корекции от 8 юли бяха приети към основния клон на предстоящото издание на glibc 2.32. Изпълнението включва две корекции − первый за многоархивното изпълнение на memcpy за ARMv7 и втори за общата реализация на асемблерния език на memcpy() и memmove() за ARM.

Проблемът засяга милиони ARMv7 устройства, работещи с Linux, и без подходяща актуализация собствениците са изложени на риск, когато ги свързват към мрежата (достъпни в мрежата услуги и приложения, които приемат входни данни без ограничения на размера, могат да бъдат атакувани). Например експлойтът, подготвен от изследователите, идентифицирали уязвимостта, показва как да атакувате HTTP сървър, вграден в автомобилна информационна система, като изпратите много голяма GET заявка и получите root достъп до системата.

Източник: opennet.ru