В течение последних нескольких дней дело о действиях группы исследователей из Университета Миннесоты, поскольку с точки зрения многих такие действия по поводу внесения уязвимостей в ядро Linux не имеют оправдания.
И хотя группа Исследователи Университета Миннесотаопубликовать открытое письмо с извинениями, чье принятие изменений в ядре Linux было заблокировано Грег Кроа-Хартман, раскрыл подробности исправлений, отправленных разработчикам ядра, и переписка с сопровождающими, связанными с этими исправлениями.
Примечательно, что все проблемные патчи были отклонены По инициативе сопровождающих ни один патч не был одобрен. Этот факт проясняет, почему Грег Кроа-Хартман действовал так жестко, поскольку непонятно, что бы сделали исследователи, если бы патчи были одобрены сопровождающим.
Ретроспективно, утверждали, что намеревались сообщить об ошибке и они не позволяли патчам попадать в Git, но неясно, что они на самом деле будут делать и как далеко они могут зайти.
Всего в августе 2020 года с анонимных адресов acostag.ubuntu@gmail.com и jameslouisebond@gmail.com (письмо Джеймса Бонда) было отправлено пять патчей: два правильных и три со скрытыми ошибками, создавая условия для появления уязвимости.
Каждый патч содержал от 1 до 4 строк кода. Основная идея плохих патчей заключалась в том, что устранение утечки памяти могло создать условия для уязвимости с двойным освобождением.
Проект направлен на повышение безопасности процесса установки исправлений в OSS. В рамках проекта мы изучаем возможные проблемы с процессом установки исправлений OSS, включая причины проблем и предложения по их устранению.
Фактически, это исследование выявляет некоторые проблемы, но его цель состоит в том, чтобы призвать к усилиям по улучшению
процесс исправления, чтобы побудить к дополнительной работе по разработке методов тестирования и проверки исправлений и, наконец, для повышения безопасности ОС.Основываясь на этих исправлениях, мы обобщаем их шаблоны, изучаем конкретные причины, по которым исправления, вводящие ошибки, трудно выявлять (с помощью как качественного, так и количественного анализа), и, что наиболее важно, даем предложения по решению проблемы.
Первый проблемный патч устранил утечку памяти, добавив вызов kfree () перед возвратом управления в случае ошибки, но создание условий для доступа к области памяти после ее освобождения (use-after-free).
Указанный патч был отклонен разработчиком., который определил проблему и указал, что год назад кто-то уже пытался предложить подобное изменение, и оно было первоначально принято, но отклонено в тот же день после выявления условий уязвимости.
Второй патч также содержал условия для проблемы износа после выпуска.. Указанный патч не был принят сопровождающим, который отклонил патч из-за другой проблемы с list_add_tail, но не заметил, что указатель "chdev" может быть освобожден в функции put_device, которая используется следующей при вызове dev_err (& chdev -> dev ..). Однако патч не был принят, хотя и по причинам, не связанным с уязвимостью.
Любопытно, изначально предполагалось, что 4 патча из 5 имеют проблемы, но сами исследователи ошиблись и в проблемном патче, по их мнению, было предложено правильное решение, без предполагаемых условий использования памяти после запуска.
В этой работе мы представляем концепцию «незрелой уязвимости», когда условие уязвимости отсутствует, но оно может стать реальным, когда условие неявно
введен патчем для другой ошибки.Мы также разрабатываем инструменты, которые помогают нам находить места кода, которые могут пострадать.
исправлений, вводящих ошибку, и предлагать, что может затруднить обнаружение этих исправлений.Через неделю разработчикам ядра была отправлена информация с предложением обсудить возможность продвижения уязвимостей под видом тривиальных исправлений утечек памяти, но ничего не было сказано о предыдущих попытках отправить вредоносные исправления.
Третий патч также был отклонен сопровождающим из-за другой ошибки без уязвимости (двойное приложение в pdev).