هزار راه کمتر برای رسیدن به دسترسی root

پژوهش امنیتی که زمانی برای هر یافته به تحقیقی جداگانه و مستمر نیاز داشت، اکنون بیش‌ازپیش می‌تواند به‌صورت فرایندی نظام‌مند اجرا شود. این سند یکی از تلاش‌های ما در این زمینه را بررسی می‌کند.

گسترش مقیاس کشف آسیب‌پذیری آسان‌تر می‌شود، اما اولویت‌بندی و اعتبارسنجی همچنان گلوگاه‌های عملیاتی هستند. نمونه‌ای اولیه ساختیم تا در یک محیط پژوهشی کنترل‌شده، نقص‌های امنیتی هسته لینوکس را جست‌وجو کند. نمونه اولیه ما ۲٬۳۰۸ یافته اولیه در هسته لینوکس را شناسایی و تحلیل کرد، ۱٬۷۲۴ آسیب‌پذیری را به‌صورت پویا بازتولید کرد و ۹۴۸ اکسپلویت ارتقای سطح دسترسی محلی (LPE) ساخت که می‌توانستند به یک کاربر محلی فاقد امتیاز ویژه، دسترسی root بدهند.

از این شواهد برای اولویت‌بندی آسیب‌پذیری‌ها جهت گزارش استفاده کردیم و وصله‌های پیشنهادی را برای بررسی نگه‌دارندگان توسعه دادیم. با پیروی از راهنمایی جامعه هسته لینوکس، از آسیب‌پذیری‌های بحرانی آغاز کردیم و برای گزارش‌ها و وصله‌های بیشتر، با شرکای Patch the Planet همکاری می‌کنیم.

در ژوئن، در چارچوب ابتکار Patch the Planet اعلام کردیم که GPT‑5.5 Cyber آسیب‌پذیری‌هایی در هسته لینوکس شناسایی کرده و برای اعتبارسنجی و گزارش آن‌ها، ۲۴ اکسپلویت ارتقای سطح دسترسی محلی ساخته است. این کار را به یک خط لوله مبتنی بر مدل سایبریِ در آستانه عرضه گسترش دادیم که کشف آسیب‌پذیری، اعتبارسنجی پویا، ارزیابی قابلیت بهره‌برداری و تولید وصله را پوشش می‌دهد. پس از پایان اجرا، پژوهشگران انسانی خروجی‌ها را بررسی کردند و آسیب‌پذیری‌های کشف‌شده را همراه با وصله‌ها گزارش دادند.

هسته لینوکس زیربنای دستگاه‌های اندرویدی، زیرساخت ابری، ابررایانه‌ها و سیستم‌های دیگری است که میلیاردها نفر از آن‌ها استفاده می‌کنند. هسته با بیش از ۴۰ میلیون خط کد، از طریق فراخوانی‌های سیستم، شبکه، سیستم‌های فایل و درایورهای دستگاه، سطح حمله گسترده‌ای ایجاد می‌کند. لینوکس را انتخاب کردیم تا بررسی کنیم مدل‌های پیشرو با چه میزان اثربخشی می‌توانند در مجموعه‌کدی با این مقیاس و اهمیت، آسیب‌پذیری‌ها را پیدا کنند و تأثیر امنیتی آن‌ها را نشان دهند.

مرحله اولیه کشف آسیب‌پذیری هزاران یافته اولیه تولید کرد؛ آن‌قدر زیاد که بازبینی و تریاژ دستی آن‌ها برای پژوهشگران امنیتی ممکن نبود. چالش عملیاتی خط لوله کشف آسیب‌پذیری ما، خودِ کشف نبود؛ بلکه تعیین این بود که کدام یافته‌ها قابل بازتولیدند، از چه مرز امنیتی عبور می‌کنند و کدام‌یک باید زودتر مورد توجه نگه‌دارندگان قرار گیرند.

مأموریت تیم سایبری OpenAI کمک به تأمین امنیت نرم‌افزارهایی است که جهان به آن‌ها متکی است. هزینه API هر مرحله را گزارش می‌کنیم تا پژوهشگران بتوانند منابع لازم برای بازتولید و گسترش این کار را ارزیابی کنند. این هزینه‌ها بازتاب مدل‌ها، پیکربندی اهداف و گردش کار استفاده‌شده در این ارزیابی‌اند. هدف گسترده‌تر ما کمک به مدافعان برای یافتن و رفع آسیب‌پذیری‌هاست تا فرصت‌های در دسترس مهاجمان کاهش یابد و هزینه بهره‌برداری از نرم‌افزار برای آن‌ها بیشتر شود.

در پایان، توجه داشته باشید که تمرکز ما در این پژوهش بر روش‌شناسی و سنجش توانایی مدل بود، نه هزینه. انتظار داریم کار مهندسی کافی روی چارچوب آزمون بتواند هزینه هر مرحله را به‌طور معناداری کاهش دهد؛ بنابراین هزینه‌های گزارش‌شده ما بیشتر یک کران بالا هستند.

نمونه اولیه پژوهش آسیب‌پذیری ما یک خط لوله پنج‌مرحله‌ای است که در هسته خود از یک مدل سایبریِ در آستانه عرضه استفاده می‌کند:

• کشف آسیب‌پذیری: عامل‌ها بخش‌های مرتبط با امنیت را در مجموعه‌کد شناسایی و برای یافتن موارد مشکوک اسکن می‌کنند.

• اعتبارسنجی پویا: عامل‌ها می‌کوشند هر مورد اولیه را در محیطی ایزوله بازتولید کنند و شواهد زمان اجرا را نگه می‌دارند. خروجی این گام، آسیب‌پذیری‌های بازتولیدشده و تأییدشده است.

• ارزیابی قابلیت بهره‌برداری: عامل‌ها می‌آزمایند که آیا آسیب‌پذیری‌های تأییدشده می‌توانند به افشای اطلاعات یا ارتقای سطح دسترسی محلی منجر شوند.

• تولید وصله: عامل‌ها برای رفع هر آسیب‌پذیری شناسایی‌شده، وصله تولید می‌کنند.

• بازبینی انسانی: پژوهشگران امنیتی پیش از گزارش به نگه‌دارندگان، اکسپلویت، وصله و درجه شدت پیشنهادی را بررسی می‌کنند.

در پایان خط لوله، سیستم تحلیل علت ریشه‌ای، یک نمونه اثبات مفهوم حداقلی که باعث ازکارافتادن می‌شود، یک وصله پیشنهادی و یک اکسپلویت کامل را در یک بسته گردآوری می‌کند تا به پژوهشگران انسانی در ارزیابی شدت آسیب‌پذیری و ارسال اصلاحات به پروژه اصلی کمک کند.

همه خطوط کد هسته لینوکس با امنیت مرتبط نیستند. خط لوله ما با استفاده از گروهی از عامل‌های کاوشگر، اهداف پراهمیت ممیزی را شناسایی کرد و سپس آن‌ها را برای اسکن آسیب‌پذیری به عامل‌های تحلیلگر سپرد.

عامل‌های کاوشگر هر پوشه و فایل را می‌خوانند و بر اساس دسترس‌پذیری برای کاربران با سطح دسترسی پایین و ارتباط با امنیت، تعیین می‌کنند کدام اهداف باید ممیزی شوند.

در این مرحله ۵٬۰۳۴ هدف ممیزی شناسایی شد: حدود ۲٫۸ میلیون خط کد، معادل تقریباً ۷٪ از کل کد هسته لینوکس. این کار هزینه ممیزی امنیتی را در مقایسه با تحلیل کل کد به‌طور چشمگیری کاهش داد. این گام ۳٬۴۲۶ دلار اعتبار API هزینه داشت.

سپس عامل‌های تحلیلگر، هر هدف ممیزی را تحلیل کردند و با گردش کاری مشابه افزونه Codex Security⁠(در یک پنجره جدید باز می‌شود)، یافته‌های اولیه تولید کردند. در نمای کلی، عامل‌های تحلیلگر کد هدف ممیزی محول‌شده را می‌خوانند تا سازوکار آن را درک کنند، مدل تهدیدش را مشخص کنند و در آن به‌دنبال آسیب‌پذیری بگردند.

عامل‌های تحلیلگر ظرف ۱۲ ساعت، پس از حذف موارد تکراری، ۲٬۳۰۸ یافته اولیه تولید کردند. این مرحله ۳۱۶٬۵۴۹ دلار اعتبار API هزینه داشت.

یافته اولیه با آسیب‌پذیری تأییدشده یکسان نیست. در این مقیاس، بررسی دستی تک‌تک گزارش‌ها برای تیم پژوهشی ما عملی نیست.

بنابراین بر اعتبارسنجی یافته‌هایی تمرکز کردیم که الف) کاربری با سطح دسترسی پایین می‌توانست به آن‌ها دسترسی پیدا کند، ب) به هیچ قابلیت ویژه‌ای نیاز نداشتند و ج) شواهد قابل‌اندازه‌گیری از تخریب حافظه تولید می‌کردند.

برای هر مورد اولیه، یک عامل تریاژ نمونه اثبات مفهوم تولید کرد و آن را در ماشین مجازی ایزوله‌ای اجرا کرد که هسته لینوکس آن به Kernel Address Sanitizer ‏(KASAN) مجهز بود. عامل هم خروجی برنامه و هم کنسول سیستم را مشاهده کرد و سپس نمونه اثبات مفهوم را به‌صورت تکرارشونده بهبود داد تا رفتار گزارش‌شده را بازتولید کند یا همه راه‌های احتمالی فعال‌کردن آن را بیازماید.

سیستم ما ظرف ۳۰ ساعت، ۱٬۷۲۴ آسیب‌پذیری را بازتولید کرد؛ حدود ۷۴٫۷٪ از ۲٬۳۰۸ یافته اولیه. بازبینی ایستای کد به‌تنهایی می‌تواند مستعد مثبت کاذب باشد؛ بنابراین دقت عامل‌های تحلیلگر و کارایی عامل‌های تریاژ در ساخت خودمختار نمونه‌های اثبات مفهوم عملی برای نزدیک به سه‌چهارم یافته‌های اولیه، ما را تحت تأثیر قرار داد.

بیشتر یافته‌های باقی‌مانده یا به سطح دسترسی بالاتر نیاز داشتند، یا به‌دلیل شرایط رقابتی دشوار، شرایط خاص فعال‌سازی (مثلاً ضرورت شکست تخصیص حافظه در خطی مشخص) یا اعتبارسنجی زمان‌بر (مثلاً دورزدن شمارنده ارجاع پس از سرریز)، در زمان تعیین‌شده بازتولید نشدند. تنها ۳٫۱٪ ناشی از تحلیل نادرست مدل بود؛ در این موارد، آسیب‌پذیری گزارش‌شده بر فرض یک شرط ناممکن استوار بود.

مرحله اعتبارسنجی در مجموع ۷۳٬۳۳۰ دلار اعتبار API هزینه داشت. در خط لوله اعتبارسنجی ما، برای تأیید اینکه یک یافته اولیه واقعاً آسیب‌پذیری است، تولید نمونه اثبات مفهوم لازم بود. مشاهده کردیم این فرایند از ارائه توصیه صرفاً بر پایه تحلیل ایستا پرهزینه‌تر است و هزینه تلاش برای اعتبارسنجی موارد مثبت واقعی و مثبت کاذب مشابه است. بنابراین حذف زودهنگام مثبت‌های کاذب در خط لوله، صرفه اقتصادی فرایند را به‌طور معناداری افزایش می‌دهد.

اعتبارسنجی مشخص می‌کند که یک آسیب‌پذیری واقعی است، اما نشان نمی‌دهد رفع آن چقدر فوریت دارد. برای مثال، آسیب‌پذیری‌ای که امکان ارتقای سطح دسترسی محلی را فراهم می‌کند، نسبت به موردی که فقط می‌تواند باعث منع سرویس محلی شود، اولویت بیشتری دارد. با وجود ۱٬۷۲۴ آسیب‌پذیری تأییدشده، وظیفه بعدی شناسایی یافته‌هایی بود که بیشترین تأثیر بالقوه را بر امنیت داشتند.

یک عامل غربالگری اولیه، هر گزارش، لاگ ازکارافتادن و کد منبع مرتبط را به‌صورت ایستا بررسی کرد. معیارهای این عامل عمداً آسان‌گیرانه بود تا یافته‌های بالقوه جدی کنار گذاشته نشوند؛ در عین حال، موارد فاقد مسیر بهره‌برداری محتمل را حذف می‌کرد. با این کار، نتایج به ۳۱۳ مورد احتمالی نشت اطلاعات و ۱٬۲۳۸ مورد احتمالی ارتقای سطح دسترسی محلی محدود شد.

سپس عامل‌های توسعه اکسپلویت (ExploitDev) این موارد را در ماشین‌های مجازی ایزوله آزمودند که حفاظت‌های یک توزیع استاندارد لینوکس در آن‌ها فعال بود؛ از جمله جلوگیری از اجرا در حالت ناظر (SMEP)، جلوگیری از دسترسی در حالت ناظر (SMAP)، تصادفی‌سازی چیدمان فضای آدرس هسته (KASLR) و HARDENED_USERCOPY. این کار به جلوگیری از ارزیابی‌های غیرواقع‌بینانه‌ای کمک کرد که به غیرفعال‌بودن حفاظت‌ها وابسته بودند.

عامل‌ها ۲۹۱ نمونه اثبات مفهوم نشت اطلاعات و ۱٬۱۶۹ اکسپلویت عملی ارتقای سطح دسترسی محلی تولید کردند که می‌توانستند به کاربران محلی فاقد امتیاز ویژه، دسترسی root بدهند.

گونه‌های مختلف آسیب‌پذیری‌ها را تحلیل کردیم و برای آسیب‌پذیری‌های زیربنای آن اکسپلویت‌ها، ۹۴۸ وصله متمایز ساختیم. از این عدد برای تعیین تعداد کل موارد LPE منحصربه‌فرد استفاده می‌کنیم. توسعه اکسپلویت‌های موفق به‌طور میانگین ۳۵۹ دلار اعتبار هزینه داشت. در نتیجه، آزمودن قابلیت بهره‌برداری از آسیب‌پذیری‌های کشف‌شده برای مدافعان نسبتاً کم‌هزینه است.

عامل غربالگری اولیه آسیب‌پذیری‌ها ۴۴٬۱۹۴ دلار اعتبار API هزینه داشت. مرحله بهره‌برداری در مجموع ۷۷۵٬۹۲۹ دلار اعتبار API هزینه داشت: ۸۴٬۹۲۹ دلار برای پردازش موارد احتمالی نشت اطلاعات و ۶۹۱٬۰۰۰ دلار برای موارد احتمالی ارتقای سطح دسترسی محلی.

به‌طور میانگین، پردازش یک مورد احتمالی ارتقای سطح دسترسی محلی (۵۵۸ دلار) تقریباً دو برابر پردازش یک مورد احتمالی نشت اطلاعات (۲۷۱ دلار) هزینه داشت. دلیلش این بود که نمونه‌های اثبات مفهوم نشت اطلاعات از مرحله اعتبارسنجی منتقل شده بودند و برای استفاده در اکسپلویت به تغییرات کمتری نیاز داشتند. در مقابل، ساخت اکسپلویت از یک مورد احتمالی LPE به گام‌های اضافی بسیاری نیاز داشت؛ مانند برنامه‌ریزی راهبرد بهره‌برداری، شناسایی اشیای آسیب‌پذیر مناسب، دورزدن سازوکارهای حفاظتی و موارد دیگر. همچنین مشاهده کردیم تلاش‌های ناموفق بهره‌برداری (۳٬۹۲۲ دلار برای ۶۹ مورد) بسیار بیشتر از تلاش‌های موفق (۳۶۰ دلار برای ۱٬۱۶۹ مورد) هزینه داشتند. دلیل این تفاوت، چند آسیب‌پذیری دشوار برای بهره‌برداری بود؛ مانند شرایط رقابتی. تعریف یک شرط منطقی برای انصراف، مثلاً توقف تلاش پس از یک ساعت بدون پیشرفت، می‌توانست هزینه ExploitDev را به‌طور چشمگیری کاهش دهد.

سیستم برای هر آسیب‌پذیری تأییدشده یک وصله نیز تولید می‌کند. کد منبع مرتبط را در اختیار مدل می‌گذاریم و از آن می‌خواهیم بهترین شیوه‌های وصله‌نویسی را رعایت کند؛ مانند انجام بررسی‌های ایستا روی وصله، پیروی از روش‌های توسعه نرم‌افزار در کد پیرامونی و تحلیل گونه‌های مختلف آسیب‌پذیری برای اطمینان از کامل‌بودن وصله.

با پیروی از پیشنهاد جامعه هسته لینوکس، تاکنون صدها گزارش و وصله برای آسیب‌پذیری‌های بحرانی ارسال کرده‌ایم و با شرکای Patch the Planet همکاری می‌کنیم تا وصله‌های بقیه موارد را به‌تدریج بفرستیم. این کار بخشی از تعهد گسترده‌تر ما در Daybreak برای حمایت از پروژه‌های متن‌باز است.

در این بخش، آموخته‌ها، تأملات و تحلیل‌های تکمیلی این پژوهش را ارائه می‌کنیم.

در طول این پژوهش، شاهد اقدام سریع نگه‌دارندگان لینوکس برای رفع آسیب‌پذیری‌ها و محافظت از کاربران بودیم. اسکن در اواسط اکتبر ۲۰۲۶ روی آخرین نسخه هسته لینوکس انجام شد. وقتی اسکن خودمختار و تحلیل دستی پس از ۱۰ روز به پایان رسید، ۶۱ آسیب‌پذیری LPE در پروژه اصلی وصله شده بود، ۴۳ مورد وصله‌هایی در مرحله آماده‌سازی داشتند و ۲۹۹ مورد به‌صورت عمومی در حال گزارش و بحث بودند.

از نگه‌دارندگان لینوکس که با فوریت برای وصله‌کردن مشکلات شناسایی‌شده تلاش کرده‌اند و همچنین از جامعه گسترده‌تر امنیت که یافته‌های خود را به اشتراک می‌گذارد، بسیار سپاسگزاریم. برای تأمین امنیت نرم‌افزارهای جهان، به چنین واکنش جمعی‌ای نیاز داریم. سرعت بالای افشا و وصله‌کردن آسیب‌پذیری‌ها همچنین نشان می‌دهد که به‌روز نگه‌داشتن نرم‌افزار برای کاربران و شرکت‌ها تا چه اندازه حیاتی است.

نکته کلیدی: تریاژ خودکار باید چرخه سریع وصله‌کردن را در نظر بگیرد. اعتبارسنجی دوباره یافته‌ها با آخرین کد، از جمله کد تازه‌ای که پس از اسکن اولیه ادغام شده، به جلوگیری از گزارش‌های تکراری یا منسوخ کمک می‌کند. این کار توجه را بر آسیب‌پذیری‌های رفع‌نشده متمرکز می‌کند و بدون افزودن بار بازبینی غیرضروری، شواهدی در اختیار نگه‌دارندگان می‌گذارد که می‌توانند بر مبنای آن اقدام کنند.

هنگام توسعه خط لوله در اواخر ژوئیه ۲۰۲۶، GPT‑5.6 Sol تعداد ۱۶۶ آسیب‌پذیری LPE منحصربه‌فرد را یافت و از آن‌ها بهره‌برداری کرد؛ با هزینه کل ۵۱۳٬۶۹۰ دلار اعتبار API.

در اسکن دوم، در اواسط اکتبر ۲۰۲۶، مدل سایبری جدیدتر ۹۴۸ آسیب‌پذیری LPE منحصربه‌فرد را یافت و از آن‌ها بهره‌برداری کرد؛ با هزینه کل ۱٬۲۱۳٬۴۳۰ دلار اعتبار API. در هر دو دور پژوهش، آخرین وضعیت شاخه master هسته لینوکس در همان زمان را اسکن کردیم.

نکته کلیدی: با بهبود توانایی مدل‌ها، کدی را که قبلاً ممیزی شده دوباره اسکن کنید. یک مدل توانمندتر ممکن است آسیب‌پذیری‌هایی را آشکار کند که مدل‌های قبلی از دست داده‌اند، حتی با استفاده از همان چارچوب آزمون پژوهشی.

۱۶۶ اکسپلویت ساخته‌شده توسط عامل‌ها را نمونه‌گیری کردیم و روش‌های بهره‌برداری به‌کاررفته در آن‌ها را تحلیل کردیم. تا جایی که می‌دانیم، عامل‌ها در اکسپلویت‌های نمونه‌گیری‌شده از ۱۰ روش جدید بهره‌برداری استفاده کرده‌اند. روش‌های بهره‌برداری را با متخصصان مستقل بهره‌برداری از هسته در میان گذاشتیم و این روش‌ها برای آن‌ها نیز تازه بودند.

از این ۱۰ روش، دو مورد اشیای کشسانِ ماندگارِ جدیدی هستند که مدل برای پاشش اشیا در کش هدف هسته به کار برد؛ دو مورد روش‌های جدید آرایش صفحات حافظه برای افزایش قابلیت اطمینان اکسپلویت‌اند؛ پنج مورد روش‌های جدیدِ صرفاً مبتنی بر داده‌اند که مستقیم یا از طریق نوشتن دلخواه به ارتقای سطح دسترسی می‌رسند؛ و روش دیگر به سردرگمی نوع دلخواه مربوط است. به‌دلایل ایمنی، از انتشار جزئیات فنی کامل این روش‌های جدید بهره‌برداری در این مطلب خودداری می‌کنیم.

نکته کلیدی: مدل‌های پیشرو صرفاً الگوهای شناخته‌شده کد آسیب‌پذیر را تطبیق نمی‌دهند یا تنها از روش‌های شناخته‌شده بهره‌برداری استفاده نمی‌کنند؛ آن‌ها خلاقیت و رویکردهای نوآورانه نشان می‌دهند.

بخش مهمی از مأموریت تیم ما، اندازه‌گیری هزینه یافتن و بهره‌برداری از آسیب‌پذیری‌ها و استفاده از این شواهد برای هدایت سرمایه‌گذاری دفاعی است. هدف ما کمک به مدافعان برای رفع آسیب‌پذیری‌ها پیش از استفاده مهاجمان از آن‌هاست، و اینکه بهره‌برداری از نرم‌افزار را برای مهاجمان از نظر اقتصادی ناموجه کنیم. اندازه‌گیری هزینه‌های بهره‌برداری کمک می‌کند ارزیابی کنیم این چالش با بهبود توانایی مدل‌ها چگونه تغییر می‌کند. در این بخش، هزینه اجرای خط لوله خود را با پاداش برنامه‌های جایزه کشف باگ برای آسیب‌پذیری‌های شناسایی‌شده مقایسه می‌کنیم.

ماشین‌های مجازی هدف در آزمایش ما، یک سیستم‌عامل دسکتاپ با تنظیمات پیش‌فرض را اجرا می‌کردند، نه هدفی که عمداً ضعیف شده باشد؛ مدل تهدید نیز همان مدلی بود که در مسابقات امنیت سایبری (مانند Pwn2Own⁠(در یک پنجره جدید باز می‌شود) و TyphoonPWN⁠(در یک پنجره جدید باز می‌شود)) استفاده می‌شود. در گذشته، Pwn2Own و TyphoonPWN برای اکسپلویت‌های ارتقای سطح دسترسی محلی هسته لینوکس به‌ترتیب ۲۰٬۰۰۰ و ۷۰٬۰۰۰ دلار جایزه کشف باگ تعیین کرده بودند. اگر این مبالغ پیشین جایزه را برای ۹۴۸ اکسپلویت در نظر بگیریم، ارزش فرضی آن‌ها ۱۸٫۹ تا ۶۶٫۳ میلیون دلار خواهد بود؛ تقریباً ۱۶ تا ۵۵ برابر هزینه خط لوله ما.

خط لوله خود را در برنامه پاداش آسیب‌پذیری kernelCTF⁠(در یک پنجره جدید باز می‌شود) گوگل نیز آزمودیم؛ هدف این برنامه هسته لینوکسی مقاوم‌سازی‌شده با سطوح حمله کاهش‌یافته است. خط لوله را در محیط kernelCTF روی آخرین نسخه هسته لینوکس اجرا کردیم؛ این نسخه با سازوکار حفاظتی SLAB_VIRTUAL در kernelCTF سازگار نبود، پس آن را از پیکربندی حذف کردیم. حاصل کار ۲۵ نمونه اثبات مفهوم نشت اطلاعات و ۲۱ اکسپلویت ارتقای سطح دسترسی محلی بود. برای مقایسه، تا زمان نگارش این متن، kernelCTF در سال ۲۰۲۶ تعداد ۲۶ اکسپلویت تأییدشده LPE روز صفر را پذیرفته است. کل این دور پژوهش ۱۱۲ ساعت طول کشید و حدود ۳۲٬۹۳۶ دلار اعتبار API هزینه داشت؛ ۸۳٫۷٪ هزینه API مربوط به کشف آسیب‌پذیری بود. اگر این ۲۱ آسیب‌پذیری در برنامه پذیرفته می‌شدند، حدود ۱٫۵ میلیون دلار جایزه به آن‌ها تعلق می‌گرفت؛ تقریباً ۴۵ برابر هزینه.

نکته کلیدی: بر اساس مبالغ پاداش اعلام‌شده عمومی و با مدل‌های فعلیِ دارای توانایی سایبری، خط لوله پژوهش آسیب‌پذیری ما در زمان انجام این پژوهش سود خالص داشت. مدافعان باید نرم‌افزار خود را پیش‌دستانه تحلیل کنند تا بهره‌برداری از آن برای مهاجمان از نظر اقتصادی ناموجه شود.

در مرحله ارزیابی قابلیت بهره‌برداری، به عامل‌های ExploitDev یک گزارش آسیب‌پذیری داده شد و از آن‌ها خواستیم یک اکسپلویت کاملاً عملی بسازند. خط لوله ما زمانی یک آسیب‌پذیری را بهره‌برداری‌شده علامت می‌زد که دسترسی به پوسته root با موفقیت به دست می‌آمد. در یکی از اجراهای اولیه، مرحله بهره‌برداری ۲۰۰ اکسپلویت موفق ارتقای سطح دسترسی محلی گزارش کرد. اما پس از بررسی انسانی، متوجه شدیم ۲۰ مورد از آن‌ها از طریق یک آسیب‌پذیری روز صفر متفاوت با مورد محول‌شده به سطح دسترسی root رسیده‌اند. این نشان می‌دهد که حتی بهره‌برداری موفق عامل‌ها نیز به اعتبارسنجی مناسب نیاز دارد.

پس از آن، محدودیت‌های وظیفه را سخت‌گیرانه‌تر کردیم و یک بررسی مستقل افزودیم تا تأیید کند هر اکسپلویت نهایی از آسیب‌پذیری محول‌شده به خود استفاده می‌کند.

نکته کلیدی: در پژوهش امنیتی خودمختار، علاوه بر خود نتیجه، مسیر رسیدن به آن را نیز تأیید کنید؛ ایزوله‌سازی، پایش و بررسی‌های مستقل از کنترل‌های ضروری‌اند.

در آغاز این پژوهش، این تصمیم طراحی را بررسی کردیم که آیا برای بهبود توانایی سایبری عامل، باید سازوکار هماهنگ‌سازی سنگینی پیرامون آن بسازیم یا نه. نتیجه ما نشان داد که مدل‌های قوی‌تر به هماهنگ‌سازی سبک‌تر و راهنمایی گام‌به‌گام کمتری نیاز دارند. همچنین، بهبود اندک حاصل از آن هزینه نگه‌داری را توجیه نمی‌کند. در نتیجه، تصمیم گرفتیم هماهنگ‌سازی سنگین را حذف کنیم.

این آزمایش GPT‑5.5 Cyber و GPT‑5.6 Cyber را مقایسه کرد. در مشاهدات ما، GPT‑5.5 Cyber همیشه نمی‌توانست زمان و شیوه مناسب استفاده از روش‌های موجود بهره‌برداری از هسته لینوکس را تشخیص دهد. سپس ۱۰۳ روش را در قالبی مناسب برای مدل گردآوری کردیم، آن‌ها را در محیط عامل قرار دادیم و از عامل خواستیم از آن‌ها استفاده کند. در میان ۶۳ مورد نامزد بهره‌برداری، این کار نرخ موفقیت را از ۷۶٫۲٪ به ۸۸٫۹٪ رساند.

وقتی این کار را با GPT‑5.6 Cyber تکرار کردیم، مدل بهتر می‌توانست به‌تنهایی روش‌های مرتبط را پیدا، انتخاب و اجرا کند. هماهنگ‌سازی روش‌ها و مهارت‌ها را حذف کردیم و این گردش کار GPT‑5.6 Cyber با هماهنگ‌سازی سبک، از گردش کار GPT‑5.5 Cyber با سازوکارهای پشتیبان سنگین‌تر بهتر عمل کرد. بازگرداندن لایه اضافی روش‌ها برای GPT‑5.6 Cyber فقط ۱٫۵ واحد درصد بهبود ایجاد کرد.

نکته کلیدی: با تغییر توانایی‌های مدل پایه، هماهنگ‌سازی و چارچوب آزمون خود را دوباره ارزیابی کنید. سازوکارهای پشتیبانی که یک نسل از مدل‌ها را به‌طور چشمگیری بهبود می‌دهند، ممکن است برای مدلی قوی‌تر ارزش چندانی نداشته باشند؛ بنابراین باید ارزش آن‌ها در برابر هزینه نگه‌داری سنجیده شود.

در ابتدا، وقتی مستقیماً از مدل می‌خواستیم وصله‌های پیشنهادی تولید کند، وصله‌هایی می‌ساخت که از نظر عملکرد درست بودند و جلوی نمونه اثبات مفهوم را می‌گرفتند، اما گاهی مشکلات دیگری ایجاد می‌کردند: کد بیش از نیاز، احتمال افت کارایی یا فاصله‌گرفتن از قراردادهای کدنویسی. گاهی نیز مدل کد مرتبط را برای یافتن گونه‌های دیگر همان آسیب‌پذیری بررسی نمی‌کرد و در نتیجه وصله ناقص می‌ماند.

دستورالعمل‌های تکمیلی و اصلاحات تکرارشونده در فرایند تولید وصله، کیفیت وصله‌ها را بهتر کرد. این نشان می‌دهد که با مدیریت مناسب، وصله‌های امنیتی تولیدشده با هوش مصنوعی می‌توانند درست، حداقلی و سازگار با قراردادهای کدنویسی موجود باشند. پژوهش در این حوزه فعالانه ادامه دارد و معتقدیم با مدل‌های آینده، این کار آسان‌تر و مؤثرتر خواهد شد. در چند مورد، نمونه اولیه پژوهشی ما توانست مشکلات وصله‌های نوشته‌شده توسط متخصصان انسانی را نیز شناسایی کند؛ این مشکلات پیش از ادغام وصله‌ها رفع شدند.

نکته کلیدی: مدل‌ها می‌توانند فرایند وصله‌کردن را سریع‌تر کنند، اما مهارت‌ها و چارچوب‌های آزمون وصله‌کردن ممکن است به اصلاحات تکرارشونده نیاز داشته باشند تا اطمینان حاصل شود وصله‌ها الزامات عملکردی و غیرعملکردی را به‌طور قابل‌اعتماد برآورده می‌کنند. همچنین توصیه می‌کنیم از مدل‌ها برای بازبینی وصله‌های انسانی و تولیدشده با هوش مصنوعی از دید مهاجم استفاده شود؛ این کار می‌تواند مشکلاتی مانند امکان دورزدن وصله، نادیده‌گرفتن مسیرها یا گونه‌های دیگر حمله و موارد دیگر را شناسایی کند.

در اجرای kernelCTF، نمونه اولیه پژوهشی ما علاوه بر ۲۱ اکسپلویت روز صفر هسته لینوکس، یک آسیب‌پذیری در QEMU TCG نیز یافت و از آن بهره‌برداری کرد. عامل تحلیلگر مأمور تحلیل کد ورود فراخوانی سیستم بود و هنگام نوشتن برنامه‌هایی برای آزمایش گذار بین سطوح دسترسی، با ازکارافتادن غیرمنتظره هسته مواجه شد. این عامل ازکارافتادن را تریاژ کرد، بدون دسترسی به کد منبع QEMU منشأ مشکل را تا QEMU TCG ردیابی کرد و آسیب‌پذیری را در گزارش گنجاند. سپس عامل ExploitDev با موفقیت یک اکسپلویت ارتقای سطح دسترسی محلی برای این آسیب‌پذیری ساخت. هنگام تحلیل دستی اکسپلویت‌ها به این آسیب‌پذیری QEMU پی بردیم و تأیید کردیم که در پروژه اصلی QEMU رفع شده، اما در نسخه منتشرشده‌ای که در آزمایش استفاده می‌شد، هنوز وجود داشته است.

نکته کلیدی: مدل‌های پیشروی دارای توانایی سایبری می‌توانند آسیب‌پذیری‌های زیرساخت آزمون را پیدا کنند. توصیه می‌کنیم پیش از انجام پژوهش تهاجمی آسیب‌پذیری، هر بخش از زیرساخت آزموده شود. ما زیرساخت خود را پیش‌دستانه آزموده‌ایم و آسیب‌پذیری‌های بسیاری را در Kata،‏ Moby/Docker،‏ gVisor و پروژه‌های دیگر افشا و وصله کرده‌ایم.

هدف ما این است که توانایی روزافزون مدل‌ها را به مزیتی پایدار برای کسانی تبدیل کنیم که امنیت اینترنت را تأمین می‌کنند. این پژوهش نشان می‌دهد که می‌توان از توانایی سایبری رو‌به‌رشد مدل‌های پیشرو برای جست‌وجوی مؤثر آسیب‌پذیری‌ها در نرم‌افزارهای پیچیده‌ای مانند هسته لینوکس استفاده کرد. مقاوم‌سازی پروژه‌های نرم‌افزاری حیاتی مانند لینوکس و دیگر پروژه‌های متن‌باز می‌تواند از بسیاری از سیستم‌ها و کاربران متکی به آن‌ها محافظت کند.

از طریق Patch the Planet، از ابتکارهای Daybreak، قصد داریم این پژوهش را به پروژه‌های نرم‌افزاری حیاتی بیشتری گسترش دهیم و در کنار نگه‌دارندگان و شرکای امنیتی، روش‌های قابل‌اعتمادی برای وصله‌کردن خودکار توسعه دهیم. می‌خواهیم پیوسته فرصت‌های در دسترس مهاجمان را کاهش دهیم و هزینه یافتن و بهره‌برداری از آسیب‌پذیری‌ها را بالا ببریم، تا جایی که منفعت مورد انتظار دیگر حمله را توجیه نکند.

هر نسل از مدل‌ها باید به ما کمک کند نرم‌افزاری بسازیم که نفوذ به آن برای نسل بعدی دشوارتر باشد. به تلاش برای ساختن اینترنتی امن ادامه خواهیم داد که هرکس بتواند با لذت بر بستر آن دست به خلق بزند.