باگ ۱۷ساله FreeBSD رو با مدلهای اوپنویت محلی پیدا کرد
هوش مصنوعیخلاصهٔ کاملتر
نویسنده میگه پیشنمایش Claude Mythos تو آوریل ۲۰۲۶ لحظهای بود که «AI روز-صفر پیدا میکنه» از حالت تئوری دراومد، چون یه مدل فرانتیر تونست CVE-2026-4747 رو پیدا کنه؛ یه RCE هفدهساله تو احراز هویت RPCSEC_GSS تو FreeBSD. یه هفته بعد، Stanislav Fort از AISLE یه ضدتز منتشر کرد و همون باگ رو با مدل ارزون gpt-5.4-nano و پایپلاینِ nano-analyzer با هزینه زیر ۱۰۰ دلار بازتولید کرد. ادعاش این بود که سیستم (داربست، پرامپتها، شکل پایپلاین و دورهای triage) بیشتر از خودِ مدل کار میکنه.
نویسنده میخواست همین رو یه پله پایینتر تو منحنی هزینه امتحان کنه: همون پایپلاین، همون CVE، ولی روی مدلهای متنبازی که خودش میتونه اجرا کنه — openai/gpt-oss-20b و google/gemma-4-31b-it، هر دو رو یه GPU مصرفی. اسکنرِ AISLE سه مرحله داره: یه context briefing برای نقشهبرداری سطح حمله هر فایل، یه مرحله اسکن که با چندتا سؤال تحلیلی کاندیداهای رتبهبندیشده برمیگردونه، و یه مرحله triage چندنوبتی که با یه مدل داورِ جدا تصمیم میگیره چی graduate بشه.
خود باگ تو تابع svc_rpc_gss_validateه: یه طول کنترلشده توسط مهاجم (oa_length که از شبکه میآد) بدون هیچ کران بالایی، فقط با یه چک «غیرصفر بودن»، با memcpy تو یه بافر استک ۱۲۸بایتی کپی میشه و سرریزش میکنه. وقتی فقط همین یه فایل رو به مدلها بدی، هر دو مدل سرراست باگ رو میگیرن.
ولی تست واقعی، اسکن کل زیرسیستم sys/rpc/ با حدود ۵۰ فایل و ۲۰هزار خطه. تو اجرای اول روی Gemma، مدل یه چکِ کرانی که اصلاً تو کد نبود رو از خودش ساخت، سرریز واقعی رو به یه مسئله جزئیِ alignment تنزل داد و قبل از triage حذفش کرد. تو اجرای روی gpt-oss، باگ به triage رسید ولی سه نوبت رأیگیری به U/V/U خورد، به UNCERTAIN نرمال شد و افتاد. نویسنده میگه پایپلاین خراب نشد چون مدل غلط بود؛ خراب شد چون مدل فقط یکبار از سهبار درست به نظر میرسید.
نکتهای که نویسنده روش تأکید میکنه اینه که این «از دست دادن»ها با اجرای دوباره از بین میرن. اسکن Gemma روی همون فایل، هفدهبار از هفدهبار سرریز رو گرفت؛ triage مربوط به gpt-oss هم تو یازدهبار از چهاردهبار باگ رو نگه داشت. مشکل واقعی، misها نیست، نویزه: اجرای اول، ۳۰ فایندینگ رو VALID کرد که نویسنده همهرو با سورس چک کرد و فقط یکیشون نقص واقعی بود (اونم نه خودِ CVE، یه deadlock بیربط).
راهحلِ نویسنده تغییرِ مدل نبود، تغییرِ سیستم بود: یه مرحله reachability_filter اضافه کرد که هر فایندینگ VALID رو وامیداره تا به یه نقطه ورود traceback بشه، callerها رو grep کنه و چک کنه طولِ ادعاشده واقعاً توسط مهاجم کنترلمیشه یا فقط kernel-setه، و هرچی dead code یا از قبل کراندار باشه رو رد کنه. روی Gemma ۳۰ تا به ۵ و روی gpt-oss ۲۱ تا به ۴ رسید، در حالی که CVE تو هر دو حفظ شد. نویسنده میگه این همون اهرمیه که AISLE کشید: سیستم رو بهتر کن، نه مدل رو.
نکات کلیدی:
- باگ یه سرریز استکه: طولِ کنترلشده توسط مهاجم بدون کران بالا با memcpy تو بافر ۱۲۸بایتی کپی میشه.
- detection رو باید بهصورت نرخ سنجید نه یه اجرا؛ یه miss تکی معمولاً نویزِ تکاجراست.
- مشکل اصلیِ مدلهای محلی، پیدا نکردن باگ نیست؛ غرقشدن باگ واقعی زیر false positiveهاست.
- یه مرحله reachability که دسترسپذیری واقعی هر فایندینگ رو چک میکنه، نویز رو شدیداً کم میکنه بدون عوضکردن مدل.
- کل کار رو روی OpenRouter حدود ۱۲ دلار خرج برداشت و اجرای محلی صفر دلاره.
