Вчора була випущена інформація про вразливість в ядрі Linux і який уже занесений у каталог CVE-2021-3609. Ця вразливість дозволяє локальному користувачеві підвищувати свої привілеї в системі через перегонові умови в реалізації протоколу CAN BCM, що виявляються у версіях 2.6.25 - 5.13-rc6 ядра Linux.
Постанова користується перевагою тому що Протокол CAN BCM дозволяє зареєструвати власний менеджер повідомлень локальної мережі контролера (CAN) і підключіть його до певного мережевого розетки. Коли надходить вхідне повідомлення, викликається функція bcm_rx_handler () зловмисник може скористатися перегоновими умовами та змусити мережевий сокет закритися під час виконання bcm_rx_handler ().
Проблема виникає, коли розетка закрита і функція викликається bcm_release (), в якому звільняється пам’ять, виділена для структур bcm_op та bcm_sock, які продовжують використовуватися в обробнику bcm_rx_handler () який все ще працює, таким чином виникає ситуація, яка веде до доступу до вже звільненого блоку пам'яті (використання після вільного використання).
Це повідомлення про нещодавно повідомлену про помилку (CVE-2021-3609) у мережевому протоколі CAN BCM у ядрі Linux, починаючи з версії 2.6.25 і закінчуючи основною лінією 5.13-rc6.
Уразливість - це расова умова в net / can / bcm.c, що дозволяє ескалацію привілеїв. Спочатку про проблему повідомляв syzbot, і Норберт Слусарек виявився придатним для використання.
Атака зводиться до відкриття двох сокетів CAN BCM і прив'язки їх до інтерфейсу vcan. У першому роз’ємі ви телефонуєте sendmsg () з індикатором RX_SETUP щоб налаштувати контролер для вхідних повідомлень CAN, а на другому роз'ємі ви телефонуєте sendmsg () щоб надіслати повідомлення на перший з'єднувач.
Після надходження повідомлення, спрацьовує виклик bcm_rx_handler (), і зловмисник бере потрібний момент і закриває перший сокет, що призводить до запуску bcm_release () і запуск конструкцій bcm_op та bcm_sock, хоча робота Росії bcm_rx_handler () ще не завершено.
Маніпулюючи вмістом bcm_sock, зловмисник може замінити вказівник на функцію sk-> sk_data_ready (sk), перенаправити виконання та, використовуючи прийоми програмування, орієнтованого на повернення (ROP), перевизначити параметр modprobe_path і змусити його код працювати як root .
Використовуючи техніку ROP, зловмисник не намагається ввести свій код на згадку, але він діє шматочки машинні інструкції вже доступні у завантажених бібліотеках, що закінчується оператором return return (як правило, це кінець функцій бібліотеки).
Дозволи, необхідні для здійснення атаки, може отримати непривілейований користувач у контейнерах, створених у системах з увімкненими просторами імен користувачів. Наприклад, простори імен користувачів включені за замовчуванням в Ubuntu та Fedora, але не включені в Debian та RHEL.
Моя спроба експлуатувати зосереджена на ядрах з версією> = 5.4-rc1 з коміту bf74aa86e111. Я не досліджував використання ядер, старших за 5.4-rc1, за допомогою тасклетів, однак використання старіших ядер також здається здійсненним.
Згадується, що дослідник, який виявив вразливість, зміг підготувати експлойт отримати root-права на системи з ядрами з версії 5.4 та пізнішої версії, включаючи можливість успішної атаки на Ubuntu 20.04.02 LTS.
Робота експлоїту зводиться до побудови ланцюжка викликів до подібних блоків ("гаджетів") для отримання необхідної функціональності. Атака вимагає доступу для створення сокетів CAN та налаштованого мережевого інтерфейсу vcan.
В кінці кінців згадується, що проблема все ще зберігається для більшості дистрибутивів, але це питання днів, перш ніж будуть випущені відповідні виправлення.
Якщо вам цікаво дізнатись більше про це, Ви можете проконсультуватися за наступним посиланням.