На тисячу шляхів до root-доступу менше

Дослідження безпеки, які раніше вимагали окремого тривалого вивчення кожної знахідки, дедалі частіше можна виконувати як систематичний процес. Цей документ описує один із наших проєктів у цьому напрямі.

Пошук вразливостей стає легше масштабувати, але визначення пріоритетів і перевірка досі залишаються вузькими місцями процесу. Ми створили прототип для пошуку вад безпеки в ядрі Linux у контрольованому дослідницькому середовищі. Наш прототип виявив і проаналізував 2 308 потенційних вразливостей ядра Linux, динамічно відтворив 1 724 вразливості та створив 948 експлойтів локального підвищення привілеїв (LPE), які могли б надати непривілейованому локальному користувачеві root-доступ.

На основі цих доказів ми визначили пріоритетність повідомлення про вразливості та розробили запропоновані виправлення для перевірки супроводжувачами. Дотримуючись рекомендацій спільноти ядра Linux, ми почали з критичних вразливостей і працюємо з партнерами Patch the Planet над подальшими звітами та виправленнями.

У червні в межах нашої ініціативи Patch the Planet ми повідомили, що GPT‑5.5 Cyber виявила вразливості ядра Linux і розробила 24 експлойти локального підвищення привілеїв для їх підтвердження та підготовки звітів. Ми розширили цю роботу до конвеєра на основі майбутньої моделі для кібербезпеки, який охоплює пошук вразливостей, динамічну перевірку, оцінку можливості експлуатації та генерування виправлень. Після завершення його роботи дослідники перевірили результати й надіслали звіти про знайдені вразливості разом із виправленнями.

Ядро Linux лежить в основі пристроїв Android, хмарної інфраструктури, суперкомп’ютерів та інших систем, якими користуються мільярди людей. Ядро містить понад 40 млн рядків коду й має широку поверхню атаки через системні виклики, мережеві функції, файлові системи та драйвери пристроїв. Ми обрали Linux, щоб дослідити, наскільки ефективно передові моделі можуть знаходити вразливості та демонструвати їхній вплив на безпеку в кодовій базі такого масштабу й значущості.

Початковий етап пошуку виявив тисячі потенційних вразливостей — забагато, щоб дослідники безпеки могли вручну перевірити й класифікувати кожну. Практична складність нашого конвеєра полягала не в пошуку, а у визначенні того, які знахідки можна відтворити, яку межу безпеки вони порушують і які потребують першочергової уваги супроводжувачів.

Місія команди кібербезпеки OpenAI — допомагати захищати програмне забезпечення, на яке покладається світ. Ми наводимо витрати на API для кожного етапу, щоб допомогти дослідникам оцінити ресурси, потрібні для відтворення й розширення цієї роботи. Ці витрати відображають моделі, конфігурації цільових систем і робочий процес, використані в цьому оцінюванні. Наша ширша мета — допомагати фахівцям із захисту знаходити й усувати вразливості, звужуючи можливості зловмисників і підвищуючи для них вартість експлуатації програмного забезпечення.

Насамкінець зауважимо, що в цьому дослідженні ми зосередилися на методології та вимірюванні можливостей моделей, а не на витратах. Ми очікуємо, що достатнє інженерне вдосконалення системи harness могло б суттєво знизити витрати на кожному етапі, тому наведені суми радше є верхньою межею.

Наш прототип для дослідження вразливостей — це п’ятиетапний конвеєр, в основі якого працює майбутня модель для кібербезпеки:

• Пошук вразливостей: агенти визначають важливі для безпеки частини кодової бази та сканують їх на потенційні вразливості.

• Динамічна перевірка: агенти намагаються відтворити кожну потенційну вразливість в ізольованому середовищі та зберігають докази, отримані під час виконання. Результат цього кроку — відтворені й підтверджені вразливості.

• Оцінка можливості експлуатації: агенти перевіряють, чи можуть підтверджені вразливості призвести до розкриття інформації або локального підвищення привілеїв.

• Генерування виправлень: агенти генерують виправлення для кожної виявленої вразливості.

• Перевірка людьми: дослідники безпеки перевіряють експлойт, виправлення та запропонований рівень серйозності перед надсиланням звіту супроводжувачам.

Наприкінці роботи конвеєра система об’єднує аналіз першопричини, мінімальний демонстраційний код, що спричиняє аварійне завершення, запропоноване виправлення та повноцінний експлойт, щоб допомогти дослідникам оцінити серйозність вразливості й передати виправлення до основного проєкту.

Не кожен рядок коду ядра Linux важливий для безпеки. Наш конвеєр використовував команду агентів-розвідників, щоб визначити найважливіші об’єкти аудиту, які потім передавалися агентам-аналітикам для сканування на вразливості.

Агенти-розвідники переглядають кожну папку й файл та визначають об’єкти аудиту за їхньою доступністю для користувачів із низькими привілеями й важливістю для безпеки.

На цьому етапі було визначено 5 034 об’єкти аудиту — близько 2,8 млн рядків коду, тобто приблизно 7% усієї кодової бази ядра Linux. Це суттєво знизило вартість аудиту безпеки порівняно з аналізом усієї кодової бази. Цей крок коштував 3 426 доларів у кредитах API.

Далі агенти-аналітики проаналізували кожен об’єкт аудиту й виявили потенційні вразливості, використовуючи робочий процес, подібний до процесу плагіна Codex Security⁠(відкривається у новому вікні). Загалом агенти-аналітики читають код призначеного об’єкта аудиту, щоб зрозуміти, як він працює, визначити його модель загроз і знайти в ньому вразливості.

За 12 годин агенти-аналітики виявили 2 308 потенційних вразливостей після усунення дублікатів. Цей етап коштував 316 549 доларів у кредитах API.

Потенційна вразливість — не те саме, що підтверджена. За такого масштабу нашій дослідницькій команді непрактично перевіряти кожен звіт вручну.

Тому ми зосередилися на підтвердженні вразливостей, які а) були доступні користувачеві з низькими привілеями, б) не потребували спеціальних повноважень і в) давали вимірювані докази пошкодження пам’яті.

Для кожної потенційної вразливості агент первинного аналізу генерував демонстраційний код і запускав його в ізольованій віртуальній машині з ядром Linux та Kernel Address Sanitizer (KASAN). Агент спостерігав за виводом програми й системною консоллю, а потім ітеративно вдосконалював демонстраційний код, доки не відтворював описану поведінку або не вичерпував можливі способи її спричинити.

За 30 годин наша система відтворила 1 724 вразливості — приблизно 74,7% із 2 308 потенційних. Сам по собі статичний аналіз коду може давати хибнопозитивні результати, тому нас вразили точність агентів-аналітиків і ефективність агентів первинного аналізу, які автономно створили робочий демонстраційний код для майже трьох чвертей потенційних вразливостей.

Більшість решти потенційних вразливостей або потребували підвищених привілеїв, або не були відтворені за відведений час через складні стани гонитви, специфічні умови спрацювання (наприклад, необхідний збій виділення пам’яті в певному рядку) чи тривалу перевірку (наприклад, переповнення лічильника посилань). Лише 3,1% були наслідком неправильного аналізу моделі, коли описана вразливість передбачала неможливу умову.

Загальна вартість етапу перевірки склала 73 330 доларів у кредитах API. Ми помітили, що в нашому конвеєрі перевірки, де для підтвердження реальності вразливості потрібно було генерувати демонстраційний код, цей процес коштував дорожче, ніж формування рекомендації лише на основі статичного аналізу. При цьому витрати на спробу підтвердити істиннопозитивний і хибнопозитивний результат були подібними. Отже, відсіювання хибнопозитивних результатів на ранніх етапах конвеєра суттєво підвищує економічну ефективність процесу.

Перевірка встановлює, що вразливість реальна, але не те, наскільки терміново її потрібно усунути. Наприклад, вразливість, яка може уможливити локальне підвищення привілеїв, заслуговує на вищий пріоритет, ніж та, що може спричинити лише локальну відмову в обслуговуванні. Після підтвердження 1 724 вразливостей наступним завданням було визначити ті, що мають найбільший потенційний вплив на безпеку.

Агент попереднього відбору статично перевіряв кожен звіт, журнал аварійного завершення та відповідний вихідний код. Критерії відбору навмисно були м’якими, щоб не відкинути потенційно серйозні знахідки, водночас відсіюючи випадки без правдоподібного шляху експлуатації. Це звузило результати до 313 потенційних витоків інформації та 1 238 потенційних вразливостей локального підвищення привілеїв.

Потім агенти розробки експлойтів (ExploitDev) перевіряли ці вразливості в ізольованих віртуальних машинах із засобами захисту, увімкненими у стандартному дистрибутиві Linux, зокрема запобіганням виконанню в режимі супервізора (SMEP), запобіганням доступу в режимі супервізора (SMAP), рандомізацією розміщення адресного простору ядра (KASLR) та HARDENED_USERCOPY. Це допомогло уникнути нереалістичних оцінок, які залежали від вимкнення засобів захисту.

Агенти створили 291 демонстраційний приклад витоку інформації та 1 169 робочих експлойтів локального підвищення привілеїв, які могли надати непривілейованим локальним користувачам root-доступ.

Ми провели аналіз варіантів і розробили 948 окремих виправлень для вразливостей, які використовували ці експлойти. Саме це число ми використовуємо як загальну кількість унікальних LPE-вразливостей. Розробка успішного експлойта коштувала в середньому 359 доларів у кредитах. Це робить перевірку можливості експлуатації знайдених вразливостей відносно недорогою для фахівців із захисту.

Робота агента попереднього відбору вразливостей коштувала 44 194 долари в кредитах API. Загальна вартість етапу експлуатації склала 775 929 доларів у кредитах API: 84 929 доларів на опрацювання потенційних витоків інформації та 691 000 доларів — потенційних вразливостей локального підвищення привілеїв.

У середньому опрацювання потенційної вразливості локального підвищення привілеїв (558 доларів) коштувало приблизно вдвічі дорожче, ніж потенційного витоку інформації (271 долар). Причина в тому, що PoC витоку інформації переносилися з етапу перевірки й потребували менше змін, щоб стати придатними для використання в експлойті. Натомість розробка експлойта для потенційної LPE-вразливості вимагала багатьох додаткових кроків: планування стратегії експлуатації, визначення вразливих об’єктів для використання, обходу засобів захисту тощо. Ми також помітили, що невдалі спроби експлуатації (3 922 долари для 69 випадків) коштували значно дорожче за успішні (360 доларів для 1 169 випадків). Це було зумовлено кількома складними для експлуатації вразливостями (наприклад, станами гонитви). Розумна умова припинення спроби, наприклад зупинка після години без прогресу, значно зменшила б витрати на ExploitDev.

Для кожної підтвердженої вразливості система також генерує виправлення. Ми надаємо моделі відповідний вихідний код і вказуємо в запиті найкращі практики написання виправлень: статичні перевірки, дотримання підходів до розробки, використаних у сусідньому коді, та аналіз варіантів, щоб переконатися в повноті виправлення.

За порадою спільноти ядра Linux ми вже надіслали сотні звітів і виправлень для критичних вразливостей та працюємо з партнерами Patch the Planet, щоб поступово надіслати виправлення для решти. Ця робота — частина наших ширших зобов’язань у межах Daybreak щодо підтримки проєктів із відкритим кодом.

У цьому розділі ми ділимося спостереженнями, міркуваннями та додатковим аналізом за результатами дослідження.

Під час цього дослідження ми спостерігали, як супроводжувачі Linux оперативно усувають вразливості й захищають користувачів. Сканування проводилося на найновішому ядрі Linux у середині жовтня 2026 року. Коли за 10 днів автономне сканування та ручний аналіз завершилися, 61 LPE-вразливість уже було виправлено в основній гілці, для 43 були підготовлені виправлення, а про 299 публічно повідомляли й обговорювали їх.

Ми дуже вдячні супроводжувачам Linux за невідкладну роботу над усуненням виявлених проблем, а також усій спільноті фахівців із безпеки, яка ділиться своїми знахідками. Саме така спільна реакція потрібна для захисту програмного забезпечення в усьому світі. Швидкі темпи розкриття та виправлення вразливостей також підкреслюють, наскільки важливо користувачам і компаніям своєчасно оновлювати програмне забезпечення.

Висновок: автоматизований первинний аналіз має враховувати швидкий цикл виправлення вразливостей. Повторна перевірка знахідок на найновішому коді, зокрема доданому після початкового сканування, допомагає уникати дубльованих або застарілих звітів. Це зосереджує увагу на невиправлених вразливостях і надає супроводжувачам докази, на основі яких можна діяти, не створюючи зайвого навантаження на перевірку.

Поки ми розробляли конвеєр, наприкінці липня 2026 року GPT‑5.6 Sol знайшла й експлуатувала 166 унікальних LPE-вразливостей. Загальна вартість процесу склала 513 690 доларів у кредитах API.

Під час другого сканування, у середині жовтня 2026 року, новіша модель для кібербезпеки знайшла й експлуатувала 948 унікальних LPE-вразливостей. Загальна вартість процесу склала 1 213 430 доларів у кредитах API. В обох кампаніях ми сканували актуальну на той момент гілку master ядра Linux.

Висновок: повторно скануйте вже перевірений код у міру вдосконалення можливостей моделей. Потужніша модель може виявити вразливості, які пропустили попередні моделі, навіть із тією самою дослідницькою системою harness.

Ми відібрали 166 експлойтів, розроблених агентами, і проаналізували використані в них техніки експлуатації. Наскільки нам відомо, у відібраних експлойтах агенти використали 10 нових технік експлуатації. Ми поділилися цими техніками зі сторонніми експертами з експлуатації вразливостей ядра, і для них вони також були новими.

Із 10 технік дві використовують нові довгоживучі об’єкти змінного розміру, якими модель заповнювала цільовий кеш ядра; дві — нові способи підготовки сторінок пам’яті для підвищення надійності експлойтів; п’ять — нові техніки, що змінюють лише дані, для підвищення привілеїв безпосередньо або через довільний запис; остання техніка передбачає довільну плутанину типів. З міркувань безпеки ми не наводимо в цій публікації повних технічних подробиць цих нових технік експлуатації.

Висновок: передові моделі не просто розпізнають відомі шаблони вразливого коду чи використовують лише відомі техніки експлуатації — вони демонструють творчість і нові підходи.

Важлива частина місії нашої команди — вимірювати вартість пошуку й експлуатації вразливостей та використовувати ці дані для визначення пріоритетів інвестицій у захист. Наша мета — допомогти фахівцям із захисту усувати вразливості раніше, ніж ними скористаються зловмисники, і зробити експлуатацію програмного забезпечення економічно невигідною для нападників. Вимірювання вартості експлуатації допомагає оцінити, як це завдання змінюється з удосконаленням можливостей моделей. У цьому розділі ми порівнюємо вартість запуску нашого конвеєра з винагородами програм пошуку вразливостей за виявлені проблеми.

Цільові віртуальні машини в нашому експерименті працювали зі стандартною настільною операційною системою, а не з ослабленим захистом, за тією самою моделлю загроз, яку використовують змагання з кібербезпеки (наприклад, Pwn2Own⁠(відкривається у новому вікні), TyphoonPWN⁠(відкривається у новому вікні)). Раніше Pwn2Own і TyphoonPWN пропонували винагороди за експлойти локального підвищення привілеїв у ядрі Linux у розмірі 20 000 і 70 000 доларів відповідно. Якщо застосувати ці історичні розміри винагород до 948 експлойтів, отримаємо гіпотетичну оцінку в 18,9–66,3 млн доларів — приблизно у 16–55 разів більше за вартість роботи нашого конвеєра.

Ми також випробували наш конвеєр у межах програми винагород за вразливості kernelCTF⁠(відкривається у новому вікні) від Google, де ціллю є ядро Linux із посиленим захистом і зменшеною поверхнею атаки. Ми запустили конвеєр на найновішій версії ядра Linux у середовищі kernelCTF (ця версія несумісна із захистом SLAB_VIRTUAL у kernelCTF, тому ми прибрали його з конфігурації) й отримали 25 демонстраційних прикладів витоку інформації та 21 експлойт локального підвищення привілеїв. Для порівняння: на момент написання цього матеріалу kernelCTF прийняла 26 підтверджених LPE-експлойтів нульового дня за 2026 рік. Уся кампанія тривала 112 годин і коштувала приблизно 32 936 доларів у кредитах API, причому на пошук вразливостей припало 83,7% витрат на API. Якби програма прийняла цю 21 вразливість, винагорода склала б приблизно 1,5 млн доларів — приблизно у 45 разів більше за витрати.

Висновок: з огляду на публічні розміри виплат, на момент дослідження наш конвеєр дослідження вразливостей із поточними моделями, здатними виконувати кіберзавдання, забезпечував чистий прибуток. Фахівцям із захисту слід завчасно аналізувати своє програмне забезпечення, щоб його експлуатація стала економічно невигідною для зловмисників.

Під час оцінки можливості експлуатації агенти ExploitDev отримували звіт про вразливість і завдання створити повністю робочий експлойт. Наш конвеєр позначав вразливість як успішно експлуатовану, якщо вдавалося отримати командну оболонку з правами root. Під час одного з ранніх запусків етап експлуатації повідомив про 200 успішних експлойтів локального підвищення привілеїв. Однак після перевірки дослідниками ми з’ясували, що 20 із них отримали права root через іншу вразливість нульового дня, а не ту, яку було призначено. Це свідчить, що навіть успішна експлуатація агентами потребує належної перевірки.

Згодом ми посилили обмеження завдання й додали незалежну перевірку того, що кожен кінцевий експлойт використовував саме призначену йому вразливість.

Висновок: в автономних дослідженнях безпеки перевіряйте не лише результат, а й шлях до нього; ізоляція, моніторинг і незалежні перевірки — необхідні засоби контролю.

На початку дослідження ми розглядали, чи варто створювати складну систему оркестрації навколо агента, щоб поліпшити його можливості у сфері кібербезпеки. Наші результати свідчили, що потужніші моделі потребують простішої оркестрації та меншого супроводу. А незначне покращення не виправдовує витрат на підтримку. Тому ми вирішили відмовитися від складної оркестрації.

В експерименті порівнювали GPT‑5.5 Cyber і GPT‑5.6 Cyber. За нашими спостереженнями, GPT‑5.5 Cyber не завжди правильно визначала, коли і як застосовувати наявні техніки експлуатації вразливостей ядра Linux. Тоді ми зібрали 103 техніки у зручному для моделі форматі, надали до них доступ у середовищі агента й попросили його використовувати їх. На 63 потенційних об’єктах експлуатації це підвищило частку успіхів із 76,2% до 88,9%.

Коли ми повторили це з GPT‑5.6 Cyber, модель краще знаходила, вибирала й застосовувала відповідні техніки самостійно. Ми прибрали оркестрацію технік і навичок, і цей процес із GPT‑5.6 Cyber та мінімальною оркестрацією перевершив процес із GPT‑5.5 Cyber і складнішими допоміжними механізмами. Повернення додаткового шару технік для GPT‑5.6 Cyber дало лише незначне покращення на 1,5 відсоткового пункту.

Висновок: переглядайте оркестрацію та систему harness у міру зміни можливостей базових моделей. Допоміжні механізми, що суттєво покращують роботу одного покоління моделей, можуть мало допомагати потужнішій моделі, тому їхню користь слід зіставляти з витратами на підтримку.

Спочатку на прямий запит згенерувати виправлення модель створювала функціонально коректні зміни, які блокували демонстраційний код, але іноді спричиняли інші проблеми: додавали зайвий код, могли погіршувати продуктивність або відхилялися від правил оформлення коду. Модель також іноді не перевіряла пов’язаний код на варіанти тієї самої вразливості, тому виправлення були неповними.

Додаткові інструкції та ітеративне вдосконалення процесу генерування поліпшили якість виправлень. Це свідчить, що за належного підходу створені ШІ виправлення безпеки можуть бути коректними, мінімальними й узгодженими з наявними правилами оформлення коду. Це активний напрям досліджень, і ми вважаємо, що з майбутніми моделями цей процес стане простішим та ефективнішим. У кількох випадках наш дослідницький прототип також виявив проблеми у виправленнях, написаних експертами, і ці проблеми усунули до внесення змін в основний код.

Висновок: моделі можуть прискорити виправлення вразливостей, але навички та системи harness для цього можуть потребувати ітеративного вдосконалення, щоб виправлення надійно задовольняли як функціональні, так і нефункціональні вимоги. Також рекомендуємо використовувати моделі для перевірки виправлень, створених людьми та ШІ, з позиції зловмисника. Це може виявити можливість обходу виправлення, невраховані шляхи чи варіанти атак та інші проблеми.

Під час запуску в kernelCTF, окрім 21 експлойта нульового дня для ядра Linux, наш дослідницький прототип також знайшов і експлуатував вразливість QEMU TCG. Агент-аналітик отримав завдання проаналізувати код входу в системні виклики. Під час написання програм для експериментів із переходами між рівнями привілеїв він зіткнувся з несподіваним аварійним завершенням ядра. Він проаналізував збій, визначив, що джерело проблеми — QEMU TCG, не маючи доступу до вихідного коду QEMU, і включив вразливість до звіту. Згодом агент ExploitDev успішно розробив для цієї вразливості експлойт локального підвищення привілеїв. Ми виявили цю вразливість QEMU під час ручного аналізу експлойтів і підтвердили, що її вже виправили в основному проєкті QEMU, але не в релізній збірці, використаній в експерименті.

Висновок: передові моделі з можливостями у сфері кібербезпеки можуть знаходити вразливості в тестовій інфраструктурі. Рекомендуємо перевіряти кожну частину інфраструктури, перш ніж досліджувати вразливості методами атаки. Ми завчасно перевірили нашу інфраструктуру, розкривши й виправивши багато вразливостей у Kata, Moby/Docker, gVisor та інших проєктах.

Наша мета — перетворити зростання можливостей моделей на тривалу перевагу для тих, хто захищає інтернет. Це дослідження демонструє, що дедалі ширші можливості передових моделей у сфері кібербезпеки можна використовувати для ефективного пошуку вразливостей у складному програмному забезпеченні, як-от ядрі Linux. Посилення захисту критично важливих програмних проєктів, як-от Linux та інших проєктів із відкритим кодом, може захистити багато систем і користувачів, які від них залежать.

Завдяки Patch the Planet, ініціативі в межах Daybreak, ми прагнемо поширити це дослідження на інші критично важливі програмні проєкти й разом із супроводжувачами та партнерами з безпеки розробити надійні засоби автоматичного виправлення вразливостей. Ми хочемо поступово звужувати можливості зловмисників і підвищувати вартість пошуку та експлуатації вразливостей, доки очікувана вигода вже не виправдовуватиме атаку.

Кожне покоління моделей має допомагати нам створювати програмне забезпечення, яке наступному поколінню буде складніше скомпрометувати. Ми й надалі працюватимемо над створенням безпечного інтернету, у якому кожен зможе із задоволенням творити нове.