Лінус Торвальдс прийняв до складу ядра документ, що регламентує процес обробки помилок, пов'язаних з безпекою, визначальний модель загроз, що пояснює, які помилки в ядрі трактуються як уразливості, і розбирає дії з помилками, виявленими за допомогою AI. Документ підготовлений Віллі Тарро (Willy Tarreau), автором HAProxy та давнім розробником ядра Linux, що відповідали за супровід кількох стабільних гілок ядра. Як основу використано домовленості, досягнуті в ході обговорення нещодавно виявлених критичних уразливостей в ядрі (1, 2, 3, 4), розкритих до публікації виправлень і для яких завдяки AI вдалося відразу створити робочі експлоїти.
Основну масу пов'язаних з безпекою помилок пропонується обробляти публічно, щоб залучити максимально широку аудиторію та знайти оптимальне рішення. В окремий приватний список розсилки пропонується надсилати тільки екстрені повідомлення про вразливості, що легко експлуатуються, загрожують багатьом користувачам і дозволяють отримати розширені привілеї або можливості.
Уразливості, виявлені за допомогою AI-асистентів, завжди пропонується обговорювати публічно, оскільки подібні проблеми часто виявляються одночасно кількома дослідниками. При цьому не слід розкривати у звіті екплоїт — достатньо згадати, що він доступний, і передати його приватно у відповідь на запит супроводжуючого.
Окремо описуються правила передачі звітів, створених з допомогою AI-асистентов. Подібних звітів надсилають дуже багато і завдяки їм іноді вдається виявляти помилки в погано відрецензованих частинах коду, але супроводжуючі часто їх ігнорують через низьку якість і неточності. Основні вимоги до звітів, створених за участю AI:
- Короткість, без води та із зазначенням суті та важливих деталей на самому початку.
- Тільки голий текст без Markdown-тегів та декорування.
- Розуміння моделі загроз і вказівка фактів, що перевіряються (наприклад, «помилка дозволяє будь-якому користувачеві отримати CAP_NET_ADMIN»), а не теоретичних вигадок і домислів про наслідки вразливості.
- Перед відправкою звіту обов'язково ретельно протестувати працездатність експлоїту, сформованого через AI, та переконатися у можливості відтворити проблему.
- Залучення AI для розробки та тестування виправлення виявленої проблеми.
За статистикою супроводжуючих більшість звітів про помилки, що надсилаються під виглядом усунення вразливостей, такими не є, і повинні оброблятися в загальному порядку як звичайні помилки. Для поділу вразливостей та звичайних помилок описано модель загроз ядра Linux. Серед можливостей та гарантій, порушення яких може розглядатися як уразливість:
- Ізоляція на рівні користувачів: доступ до файлів тільки для власника, пам'ять процесу недоступна іншим користувачам, ptrace заборонено для чужих процесів, ізоляція IPC та мережевих комунікацій.
- Захист на основі capabilities: без CAP_SYS_ADMIN не можна змінювати конфігурацію ядра, пам'ять, стан системи, без CAP_NET_ADMIN не можна змінювати налаштування мережі або перехоплювати трафік, без CAP_SYS_PTRACE не можна відстежувати процеси інших користувачів.
- Простір імен ідентифікаторів користувачів (CONFIG_USER_NS) дозволяє непривілейованим користувачам створювати свої ізольовані оточення, з яких не можна впливати на глобальний простір імен, наприклад, змінювати час, завантажувати модулі та монтувати блокові пристрої.
- Інтерфейси налагодження (/proc/kmsg, perf, debugfs), через які можна отримати доступ до конфіденційної інформації, доступні тільки після явного надання доступу адміністратором.
Можливості, які не розглядаються як уразливість:
- Використання застарілих гілок ядра.
- Складання з включенням опцій для розробників або тих, що знижують безпеку (наприклад, CONFIG_NOMMU).
- Виставляє небезпечні налаштування sysctl, опції командного рядка, права доступу до ФС, capabilities або відкриття непривілейованим користувачам доступу до привілейованих інтерфейсів (наприклад, доступ на запис у procfs і debugfs).
- Проблеми у функціях, призначених лише для розробки та налагодження ядра, таких як LOCKDEP, KASAN та FAULT_INJECTION, які не призначені для включення у робочі конфігурації.
- Проблеми в драйверах, модулях та підсистемах, що знаходяться в секції STAGING або позначені як експериментальні, небезпечні або непрацездатні.
- Використання сторонніх модулів ядра чи неофіційних форків ядра.
- Вимога надмірних привілеїв, таких як необхідність виконання дій з правами root або від користувача, що має права CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO та CAP_SYS_MODULE.
- Теоретичні атаки, що вимагають лабораторних умов, мільярдів спроб, емуляції чи модифікації обладнання, невідповідних витрат та нереалістичних конфігурацій (наприклад, системи з десятками тисяч ядер CPU).
- Обхід механізмів захисту (наприклад, ASLR) без демонстрації експлоїту. Відсутність перевірок аргументів і кодів помилок, що повертаються, не мають явних наслідків.
- Випадкові витоку інформації, непідконтрольні атакуючим, такі як залишкові дані в повідомленнях про помилки та витоку адрес/покажчиків на пам'ять ядра без прямої можливості експлуатації.
- Помилки при монтуванні пошкоджених дискових образів, якщо драйвер не заявлений як придатний для використання з носіями, що не заслуговують на довіру. Проблеми з дисковими образами, що виявляються та усуваються через запуск утиліти fsck.
- Атаки потребують фізичного доступу до обладнання, модифікації обладнання або підключення апаратних пристроїв, таких як плати для атаки на DMA та логічні аналізатори, якщо система спеціально не налаштована для захисту від подібних атак (IOMMU).
- Регресії з функціональністю та продуктивністю, що усуваються налаштуванням прав та лімітів.
Джерело: opennet.ru
