С хиляда по-малко пътища до root достъп

Изследването на сигурността, което някога изискваше отделно, продължително проучване на всяка находка, все по-често може да се извършва като систематичен процес. Този документ разглежда едно от нашите начинания в тази област.

Откриването на уязвимости все по-лесно се разширява по мащаб, но определянето на приоритети и потвърждаването остават тесни места в работния процес. Създадохме прототип за търсене на пропуски в сигурността на ядрото на Linux в контролирана изследователска среда. Нашият прототип идентифицира и анализира 2308 потенциални уязвимости в ядрото на Linux, възпроизведе динамично 1724 уязвимости и създаде 948 експлойта за локално повишаване на привилегии (LPE), които биха позволили на непривилегирован локален потребител да получи root достъп.

Използвахме тези доказателства, за да подредим уязвимостите по приоритет за докладване, и разработихме предложения за корекции, които поддържащите разработчици да прегледат. Следвайки насоките на общността на ядрото на Linux, започнахме с критичните уязвимости и работим с партньорите на Patch the Planet по допълнителни доклади и корекции.

През юни, като част от нашата инициатива Patch the Planet, споделихме, че GPT‑5.5 Cyber е идентифицирал уязвимости в ядрото на Linux и е разработил 24 експлойта за локално повишаване на привилегии, за да ги потвърди и докладва. Разширихме тази работа в автоматизиран процес, задвижван от предстоящ кибермодел, който обхваща откриване на уязвимости, динамично потвърждаване, оценка на възможността за експлоатиране и генериране на корекции. След приключването му изследователи прегледаха резултатите и докладваха откритите уязвимости заедно с корекциите.

Ядрото на Linux е в основата на устройства с Android, облачна инфраструктура, суперкомпютри и други системи, използвани от милиарди хора. С над 40 милиона реда код ядрото предоставя широка повърхност за атака чрез системни извиквания, мрежови функции, файлови системи и драйвери за устройства. Избрахме Linux, за да проучим колко ефективно авангардните модели могат да откриват уязвимости и да демонстрират въздействието им върху сигурността в кодова база с такъв мащаб и значение.

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

Мисията на екипа Cyber на OpenAI е да помага за защитата на софтуера, на който светът разчита. Посочваме разходите за API на всеки етап, за да помогнем на изследователите да оценят ресурсите, необходими за възпроизвеждане и надграждане на тази работа. Тези разходи отразяват моделите, конфигурациите на целевите системи и работния процес, използвани в тази оценка. По-широката ни цел е да помогнем на защитниците да откриват и отстраняват уязвимости, като ограничим възможностите на нападателите и увеличим разходите им за експлоатиране на софтуер.

Накрая, имайте предвид, че в това изследване се съсредоточихме върху методологията и измерването на възможностите на моделите, а не върху разходите. Очакваме, че достатъчно инженерна работа по рамката би могла значително да намали разходите на всеки етап; затова посочените от нас разходи са по-скоро горна граница.

Нашият прототип за изследване на уязвимости е автоматизиран процес от пет етапа, в чиято основа е предстоящ кибермодел:

• Откриване на уязвимости: Агентите идентифицират части от кодовата база, свързани със сигурността, и ги сканират за потенциални уязвимости.

• Динамично потвърждаване: Агентите се опитват да възпроизведат всяка потенциална уязвимост в изолирана среда и запазват доказателства от изпълнението. Резултатът от тази стъпка са възпроизведените и потвърдени уязвимости.

• Оценка на възможността за експлоатиране: Агентите проверяват дали потвърдените уязвимости биха позволили разкриване на информация или локално повишаване на привилегии.

• Генериране на корекции: Агентите генерират корекции за всяка идентифицирана уязвимост.

• Преглед от специалисти: Изследователи по сигурността преглеждат експлойта, корекцията и предложената степен на тежест, преди да ги докладват на поддържащите разработчици.

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

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

Агентите разузнавачи преглеждат всяка папка и файл и определят кои обекти да бъдат одитирани според достъпността им за потребители с ограничени привилегии и значението им за сигурността.

На този етап бяха идентифицирани 5034 обекта за одит — около 2,8 милиона реда код, или приблизително 7% от цялата кодова база на ядрото на Linux. Това значително намали разходите за одита по сигурността спрямо анализ на цялата кодова база. Тази стъпка струваше 3426 долара в API кредити.

След това агентите анализатори анализираха всеки обект на одит и изведоха потенциални уязвимости, използвайки работен процес, подобен на този в плъгина Codex Security⁠(отваря се в нов прозорец). В общи линии агентите анализатори четат кода на възложения им обект на одит, за да разберат как работи, да определят модела на заплахите за него и да потърсят уязвимости.

В рамките на 12 часа агентите анализатори изведоха 2308 потенциални уязвимости след премахване на дубликатите. Този етап струваше 316 549 долара в API кредити.

Потенциалната находка не е равнозначна на потвърдена уязвимост. При този мащаб ръчното проучване на всеки доклад е непрактично за нашия изследователски екип.

Затова се съсредоточихме върху потвърждаването на находки, които а) са достъпни за потребител с ограничени привилегии, б) не изискват специални права и в) дават измерими доказателства за повреда на паметта.

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

В рамките на 30 часа нашата система възпроизведе 1724 уязвимости — около 74,7% от 2308-те потенциални находки. Самостоятелният статичен преглед на кода може да дава фалшиви положителни резултати. Затова бяхме впечатлени от точността на агентите анализатори и ефективността на агентите за първоначална оценка, които автономно създадоха работещ демонстрационен код за почти три четвърти от потенциалните находки.

Повечето останали находки или изискваха повишени привилегии, или не бяха възпроизведени в определеното време поради трудни за възпроизвеждане състезателни условия, специфични условия за задействане (напр. необходим отказ при заделяне на памет на конкретен ред) или времеемко потвърждаване (напр. препълване на брояч на препратки). Само 3,1% се дължаха на неправилен анализ от модела, при който докладваната уязвимост предполагаше невъзможно условие.

Етапът на потвърждаване струваше общо 73 330 долара в API кредити. Установихме, че в нашия процес за потвърждаване, който трябваше да генерира демонстрационен код, за да провери дали дадена находка е реална уязвимост, това беше по-скъпо от даването на препоръка само въз основа на статичен анализ. Разходите за опитите за потвърждаване на истински и фалшиви положителни резултати бяха сходни. Затова отстраняването на фалшивите положителни резултати на по-ранен етап прави процеса осезаемо по-рентабилен.

Потвърждаването установява, че уязвимостта е реална, но не и колко спешно трябва да бъде отстранена. Например уязвимост, която би позволила локално повишаване на привилегии, заслужава по-висок приоритет от такава, която може да предизвика само локален отказ на услуга. При 1724 потвърдени уязвимости следващата задача беше да определим кои имат най-голямо потенциално въздействие върху сигурността.

Агент за предварително отсяване извърши статичен преглед на всеки доклад, запис за срив и съответния изходен код. Критериите му бяха умишлено по-свободни, за да не отхвърля потенциално сериозни находки, като същевременно отсява случаите без правдоподобен път за експлоатиране. Това стесни резултатите до 313 потенциални уязвимости с изтичане на информация и 1238 с локално повишаване на привилегии.

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

Агентите създадоха 291 демонстрационни кода за изтичане на информация и 1169 работещи експлойта за локално повишаване на привилегии, които биха могли да дадат root достъп на непривилегировани локални потребители.

Извършихме анализ на вариантите и разработихме 948 отделни корекции за уязвимостите зад тези експлойти. Използваме този брой, за да определим общия брой уникални LPE уязвимости. Разработването на успешните експлойти струваше средно 359 долара в кредити. Това прави проверката дали откритите уязвимости могат да бъдат експлоатирани сравнително евтина за защитниците.

Агентът за предварително отсяване на уязвимости струваше 44 194 долара в API кредити. Етапът на експлоатиране струваше общо 775 929 долара в API кредити: 84 929 долара за обработване на потенциални уязвимости с изтичане на информация и 691 000 долара за такива с локално повишаване на привилегии.

Средно обработването на потенциална уязвимост с локално повишаване на привилегии (558 долара) беше приблизително два пъти по-скъпо от обработването на такава с изтичане на информация (271 долара). Причината е, че демонстрационният код за изтичане на информация се пренасяше от етапа на потвърждаване и изискваше по-малко промени, за да стане използваем в експлойт. За разлика от това, разработването на експлойт от потенциална LPE уязвимост изискваше много допълнителни стъпки, като планиране на стратегия за експлоатиране, идентифициране на подходящи уязвими обекти, заобикаляне на защити и други. Забелязахме също, че неуспешните опити за експлоатиране (3922 долара при 69 случая) струваха много повече от успешните (360 долара при 1169 случая). Това се дължеше на няколко трудни за експлоатиране уязвимости (напр. състезателни условия). Определянето на разумно условие за прекратяване, например спиране на опита след един час без напредък, би намалило значително разходите за 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.

Извод: Сканирайте повторно вече одитиран код с подобряването на възможностите на моделите. По-способен модел може да разкрие уязвимости, пропуснати от по-ранни модели, дори при използване на същата изследователска рамка.

Подбрахме извадка от 166 експлойта, разработени от агентите, и анализирахме използваните в тях техники за експлоатиране. Доколкото ни е известно, агентите са използвали 10 нови техники за експлоатиране в експлойтите от извадката. Споделихме техниките с външни експерти по експлоатиране на уязвимости в ядрото и те бяха нови и за тях.

От 10-те техники две използват нови устойчиви обекти с променлив размер, чрез които моделът запълва целевия кеш на ядрото с обекти; две са нови техники за подреждане на страници в паметта, които подобряват надеждността на експлойта; пет са нови техники, работещи само с данни, за повишаване на привилегии директно или чрез произволен запис; останалата техника включва произволно объркване на типове. От съображения за безопасност не споделяме пълните технически подробности за тези нови техники за експлоатиране в тази публикация.

Извод: Авангардните модели не просто разпознават познати шаблони на уязвим код или използват само известни техники за експлоатиране — те проявяват творчески подход и разработват нови решения.

Важна част от мисията на нашия екип е да измерва разходите за откриване и експлоатиране на уязвимости и да използва тези данни, за да насочва инвестициите в защита. Нашата цел е да помогнем на защитниците да отстраняват уязвимостите, преди нападателите да могат да ги използват, и да направим експлоатирането на софтуер прекалено скъпо за нападателите. Измерването на разходите за експлоатиране ни помага да оценим как това предизвикателство се променя с подобряването на възможностите на моделите. В този раздел сравняваме разходите за изпълнението на нашия процес с наградите, предлагани от програмите за откриване на уязвимости за идентифицираните проблеми.

Целевите виртуални машини в нашия експеримент работеха със стандартна настолна операционна система, а не с умишлено отслабена защита, при същия модел на заплахите, който се използва в състезанията по киберсигурност (напр. Pwn2Own⁠(отваря се в нов прозорец), TyphoonPWN⁠(отваря се в нов прозорец)). В миналото Pwn2Own и TyphoonPWN предлагаха награди съответно от 20 000 и 70 000 долара за експлойти за локално повишаване на привилегии в ядрото на Linux. Ако приложим тези исторически размери на наградите към 948-те експлойта, получаваме хипотетична оценка от 18,9–66,3 млн. долара, приблизително 16 до 55 пъти разходите за нашия процес.

Тествахме процеса и спрямо програмата на Google за награди за уязвимости kernelCTF⁠(отваря се в нов прозорец), чиято цел е ядро на Linux с подсилена защита и намалени повърхности за атака. Изпълнихме процеса върху най-новата версия на ядрото на Linux в средата на kernelCTF и получихме 25 демонстрационни кода за изтичане на информация и 21 експлойта за локално повишаване на привилегии. Тази версия беше несъвместима със защитата SLAB_VIRTUAL в kernelCTF, затова я премахнахме от конфигурацията. За сравнение, към момента на написването 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 процентни пункта.

Извод: Преоценявайте оркестрацията и рамката си с промяната на възможностите на базовия модел. Подпомагаща структура, която значително подобрява едно поколение модели, може да носи малка полза за по-силен модел. Тази полза трябва да се преценява спрямо разходите за поддръжката ѝ.

Първоначално, когато му се задаваше директно да генерира предложения за корекции, моделът създаваше функционално правилни корекции, които блокираха демонстрационния код, но понякога въвеждаха други проблеми: повече код от необходимото, потенциални компромиси с производителността или отклонения от конвенциите за писане на код. Понякога моделът не проверяваше свързания код за варианти на същата уязвимост, което водеше до непълни корекции.

Допълнителните инструкции и последователното усъвършенстване на процеса за генериране подобриха качеството на корекциите. Това показва, че с подходящ подход генерираните от AI корекции за сигурност могат да бъдат правилни, минимални и съобразени със съществуващите конвенции за код. Това е активна област на изследване и смятаме, че с бъдещите модели процесът ще стане по-лесен и по-ефективен. В няколко случая изследователският ни прототип успя да идентифицира и проблеми в корекции, написани от експерти. Тези проблеми впоследствие бяха отстранени, преди корекциите да бъдат включени в основния код.

Извод: Моделите могат да ускорят процеса на създаване на корекции, но уменията и рамките за тази задача може да изискват последователно усъвършенстване, за да се гарантира, че корекциите надеждно изпълняват както функционалните, така и нефункционалните изисквания. Освен това препоръчваме моделите да се използват за преглед от гледната точка на нападател на корекции, създадени от хора и AI. Така могат да се открият проблеми като възможност за заобикаляне на корекцията, пропуснати пътища за атака или варианти и други.

При изпълнението в kernelCTF, освен 21-те експлойта за уязвимости от нулев ден в ядрото на Linux, изследователският ни прототип откри и експлоатира уязвимост в QEMU TCG. На агента анализатор беше възложено да анализира кода за влизане в ядрото при системни извиквания. Докато пишеше програми за експерименти с преходите между нива на привилегии, той се натъкна на неочакван срив на ядрото. Агентът направи първоначална оценка на срива и проследи проблема до QEMU TCG, без да има достъп до изходния код на QEMU, след което включи уязвимостта в доклада. Впоследствие агентът ExploitDev успешно разработи експлойт за локално повишаване на привилегии за тази уязвимост. Открихме тази уязвимост в QEMU при ръчния анализ на експлойтите и потвърдихме, че тя е отстранена в основния проект QEMU, но не и в издадената компилация, използвана в експеримента.

Извод: Авангардните модели с киберспособности могат да откриват уязвимости в тестовата инфраструктура. Препоръчваме да се тества всяка част от инфраструктурата, преди да се пристъпи към изследване на уязвимости чрез атакуващи техники. Ние проактивно тествахме инфраструктурата си, като оповестихме и отстранихме множество уязвимости в Kata, Moby/Docker, gVisor и други проекти.

Нашата цел е да превърнем нарастващите възможности на моделите в трайно предимство за хората, които защитават интернет. Това изследване показва, че нарастващите киберспособности на авангардните модели могат да се използват за ефективно търсене на уязвимости в сложен софтуер, като ядрото на Linux. Укрепването на сигурността на критично важни софтуерни проекти като Linux и други проекти с отворен код може да защити множество системи и потребители, които разчитат на тях.

Чрез Patch the Planet, инициатива в рамките на Daybreak, се стремим да разширим това изследване към още критично важни софтуерни проекти и да разработим надеждно автоматизирано създаване на корекции съвместно с поддържащите ги разработчици и партньори в областта на сигурността. Искаме постепенно да ограничаваме възможностите на нападателите и да увеличаваме разходите за откриване и експлоатиране на уязвимости, докато очакваната полза вече не оправдава атаката.

Всяко поколение модели трябва да ни помага да създаваме софтуер, който следващото поколение ще компрометира по-трудно. Ще продължим да работим за сигурен интернет, в който всеки може да създава с удоволствие.