‏گرفتن CVE با کلود کد، بدون تحویل دادن آشغال

نویسنده تو این شماره از خبرنامه‌ش تعریف می‌کنه که اولین CVEهاش رو چطوری گرفته: با Claude Code و افزونهٔ Ghidra MCP که بهش اجازه می‌ده Ghidra رو از دل کلود کنترل کنه. هدفش پیدا کردن درایورهای آسیب‌پذیر رو لپ‌تاپ گیمینگ خودش بود و برای اینکه وقتش رو سر درایورهای بی‌فایده هدر نده، یه ابزار رتبه‌بندی درایور به‌اسم cthaeh هم نوشت.

به گفتهٔ نویسنده، کلود بخش زیادی از مهندسی معکوس و نوشتن پیش‌نویس PoC رو انجام داده و این خیلی سریع‌تر از تایپ‌کردن دستی C بوده؛ ولی نکتهٔ کلیدی اینه که باید بلد باشی «درست» چه شکلیه. مدل دوست داره یه داستان قشنگ بسازه و هایپت کنه، برای همین باید مدام بکشیش عقب و مجبورش کنی باگ رو با یه PoC واقعی ثابت کنه.

اولین باگ، CVE-2026-3508 با شدت متوسط، تو درایور AsusWmiAcpi.sys بود. مشکل اینجا بود که درایور ادعای اندازهٔ ورودی رو باور می‌کرد ولی چک نمی‌کرد که واقعاً همون‌قدر داده فرستاده شده؛ نتیجه‌ش خواندن حافظهٔ کرنل فراتر از بافر معتبر (out-of-bounds read) بود که گاهی می‌تونه سیستم رو کرش کنه. ایسوس براش امتیاز CVSS حدود ۶.۸ (متوسط) داد.

دومی، CVE-2026-6737 تو درایور AsusPTPFilter.sys، یه مشکل کنترل دسترسی بود: درایور آبجکت‌های دستگاه رو بدون توصیف‌گر امنیتی صریح می‌ساخت، برای همین یه کاربر عادی محلی می‌تونست بازشون کنه و از طریق IOCTLها اطلاعات محدود تاچ‌پد رو بگیره یا از کارش بندازه. جالب اینکه این باگ حتی با شدت «پایین» هم CVE گرفت و راهکار امن‌ترش استفاده از الگوی ساخت دستگاه با دسترسی محدود به ادمین بوده.

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

نکات کلیدی:

• دو CVE واقعی ایسوس با کمک Claude Code و Ghidra MCP گرفته شد
• CVE-2026-3508: خواندن خارج از محدوده به‌خاطر باور کردن اندازهٔ ورودی
• CVE-2026-6737: کنترل دسترسی ناامن رو آبجکت‌های دستگاه درایور
• پیام اصلی: هر یافته رو با PoC ثابت کن و به مدل کورکورانه اعتماد نکن