Несколько дней назад Янн Хорн из команды Google Project Zero, который ранее выявил уязвимости Spectre и Meltdown, представил метод эксплуатации уязвимости обнаружен в сборщике мусора ядра Linux (CVE-2021-4083).
Уязвимость вызвано состоянием гонки когда очищаются файловые дескрипторы сокетов unix и потенциально позволяет непривилегированному локальному пользователю выполнять ваш код на уровне ядра.
Проблема интересно, потому что временное окно во время которого возникает состояние гонки был оценен как слишком маленький для создания реальных уязвимостей, но автор исследования показал, что даже изначально скептически настроенные уязвимости могут стать источником реальных атак, если у создателя уязвимости есть необходимые навыки и время.
Ян Хорн показал, как с помощью филигранных манипуляций можно уменьшить состояние Событие гонки, возникающее при одновременном вызове функций close() и fget() для полностью использованной уязвимости use-after-free и получения доступа к уже освобожденной структуре данных в ядре.
Возникает состояние гонки в процессе закрытия файлового дескриптора при одновременном вызове функций close() и fget(). Вызов close() может быть выполнен до выполнения fget(), что запутает сборщик элементов. неиспользуемый, так как согласно refcount файловая структура не будет иметь внешних ссылок, а останется привязанной к файловому дескриптору, т.е. сборщик мусора будет считать, что имеет монопольный доступ к структуре, но на самом деле в течение короткого промежутка времени, оставшаяся запись в таблице файловых дескрипторов будет по-прежнему указывать на то, что структура освобождается.
Чтобы увеличить вероятность вход в состояние гонки, было использовано несколько приемов, позволивших увеличить вероятность успеха холдинга на 30% при выполнении определенных системных оптимизаций. Например, для увеличения времени доступа к структуре с файловыми дескрипторами на несколько сотен наносекунд данные выбрасывались из кеша процессора за счет загрязнения кеша активностью на другом ядре ЦП, что позволяло вернуть структуру из памяти и не быстрый кэш процессора.
Вторая важная особенность было использование прерываний, генерируемых аппаратным таймером увеличить время гонки. Время было выбрано таким, чтобы обработчик прерывания срабатывал во время возникновения состояния гонки и прерывал выполнение кода на некоторое время. Чтобы еще больше задержать возврат управления, epoll сгенерировал около 50 тысяч записей в очереди, что потребовало итерации в обработчике прерывания.
Техника использование уязвимостей была раскрыта после 90-дневного периода неразглашения. Проблема
и это было исправлено в начале декабря. Исправление было включено в ядро 5.16, а также перемещено в LTS-ветки ядра и пакеты с ядром, поставляемые в дистрибутивах. Следует отметить, что уязвимость была выявлена при анализе аналогичной проблемы CVE-2021-0920, проявляющейся в сборщике мусора при обработке флага MSG_PEEK.
Обнаружена еще одна уязвимость недавно в ядре Linux это был CVE-2022-0742 что может исчерпать доступную память и удаленно вызвать отказ в обслуживании путем отправки специально созданных пакетов icmp6. Проблема связана с утечкой памяти, возникающей при обработке сообщений ICMPv6 с типами 130 или 131.
Проблема присутствует с ядра 5.13 и была исправлена в версиях 5.16.13 и 5.15.27. Проблема не затрагивала стабильные ветки Debian, SUSE, Ubuntu LTS (18.04, 20.04) и RHEL, она была исправлена в Arch Linux.
В конце концов если вам интересно узнать об этом больше примечания, вы можете проверить детали в по следующей ссылке.