Кілька днів тому Янн Хорн з команди Google Project Zero, які раніше визначали вразливості Spectre і Meltdown, представила методику використання вразливості знайдений у збірнику сміття ядра Linux (CVE-2021-4083).
Вразливість викликано станом раси коли очищаються дескриптори файлів сокету Unix і потенційно дозволяє непривілейованому локальному користувачеві виконувати ваш код на рівні ядра.
Проблема цікавий тим, що часове вікно під час якого виникає стан гонки була оцінена як занадто мала створювати реальні вразливості, але автор дослідження показав, що навіть спочатку скептичні вразливості можуть стати джерелом реальних атак, якщо у творця вразливості є необхідні навички та час.
Ян Хорн показав, як за допомогою філігранних маніпуляцій можна зменшити стан Подія гонки, яка виникає під час одночасного виклику функцій close() і fget() до повністю використаної уразливості без використання та отримання доступу до вже звільненої структури даних у ядрі.
Виникає гонка під час процесу закриття дескриптора файлу одночасно викликаючи функції 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.
В кінці кінців якщо вам цікаво дізнатись більше про це нотатки, ви можете перевірити деталі в за наступним посиланням.