خودکارسازی تولید رابط آزمون فازی با استفاده از مدل‌های زبانی بزرگ و بهینه‌سازی تکاملی

ضرورت و انگیزه پژوهش

نرم‌افزارها ستون اصلی بسیاری از خدمات حیاتی جوامع مدرن محسوب می‌شوند. امروز سامانه‌های بانکی، شبکه‌های توزیع انرژی، زیرساخت‌های ارتباطی و حتی خدمات سلامت، همگی به درستی و امنیت کد وابسته‌اند. همین وابستگی باعث شده است که یک آسیب‌پذیری نرم‌افزاری دیگر صرفاً یک خطای فنی ساده نباشد، بلکه بتواند پیامدهای اقتصادی، امنیتی و اجتماعی جدی به همراه داشته باشد. این مسئله به‌ویژه در کتابخانه‌های نوشته‌شده با زبان‌های C و C++ اهمیت بیشتری دارد؛ کتابخانه‌هایی که بسیاری از آن‌ها سال‌ها یا حتی دهه‌هاست در زیرساخت نرم‌افزارهای امروزی استفاده می‌شوند. تنها در سال ۲۰۲۴، بیش از چهل هزار آسیب‌پذیری جدید در پایگاه داده CVE ثبت شده است و بخش قابل‌توجهی از این آسیب‌پذیری‌ها به همین اکوسیستم‌های قدیمی اما همچنان پرکاربرد مربوط می‌شود.

در چنین فضایی، آزمون فازی “Fuzzing test” به یکی از مؤثرترین روش‌های کشف خودکار آسیب‌پذیری تبدیل شده است. ابزارهایی مانند AFL و libFuzzer با اجرای مکرر برنامه روی ورودی‌های جهش‌یافته، مسیرهای اجرایی جدید را شناسایی می‌کنند و ورودی‌هایی را که به کشف رفتارهای تازه منجر شوند، نگه می‌دارند و توسعه می‌دهند. موفقیت این رویکرد در پروژه‌هایی مانند OSS-Fuzz گوگل و syzkaller نشان داده است که آزمون فازی می‌تواند در مقیاس بزرگ، هزاران خطا و آسیب‌پذیری واقعی را آشکار کند.

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

مسئله پژوهش و شکاف موجود

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

در سال‌های اخیر، ابزارهای مختلفی برای تولید خودکار رابط آزمون فازی پیشنهاد شده‌اند. برای مثال، FuzzGen با تحلیل ایستای وابستگی‌های API رابط تولید می‌کند، اما پس از تولید، آن را تغییر نمی‌دهد و از بازخورد اجرای فازر برای بهبود آن استفاده نمی‌کند. ابزارهایی مانند OSS-Fuzz-Gen و HarnessAgent از مدل‌های زبانی بزرگ برای تولید رابط بهره می‌برند و می‌توانند خطاهای کامپایل را تا حدی اصلاح کنند، اما این فرایند بیشتر در سطح نحوی باقی می‌ماند. پس از آنکه کد کامپایل شد، معمولاً سازوکاری برای بهبود منطقی و تدریجی رابط وجود ندارد.

رویکرد پیشنهادی

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

مراحل فرآیند چرخه‌ی تکاملی سیستم:

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

نتایج تجربی

چارچوب پیشنهادی روی یازده کتابخانه متنوع C و C++ ارزیابی شد. در هفت مورد، یعنی بیش از ۶۳ درصد آزمایش‌ها، سیستم توانست پوشش کد قابل‌اندازه‌گیری ایجاد کند و رابط آزمون فازی را طی نسل‌های متوالی بهبود دهد. موارد ناموفق عمدتاً به وابستگی‌های پیچیده کامپایل یا APIهای بسیار خاص مربوط بودند؛ وضعیتی که در آن مدل زبانی گاهی دچار فرض‌های نادرست یا توهم‌زایی می‌شد.

برجسته‌ترین نتیجه در کتابخانه چندرسانه‌ای GPAC به دست آمد. در این مورد، پوشش لبه از ۷۵ لبه در نسل صفر به ۲۳۱ لبه در نسل هشتم رسید؛ یعنی رشدی معادل ۲۰۸ درصد. این نتیجه نشان می‌دهد که حلقه تکاملی توانسته است در طول زمان، رابط را به‌گونه‌ای تغییر دهد که مسیرهای اجرایی بیشتری فعال شوند. در مقایسه با HarnessAgent، که یکی از ابزارهای پیشرفته موجود در این حوزه است، تفاوت چشمگیر بود.

همچنین در مقایسه مستقیم با تولید یک‌باره رابط توسط مدل زبانی، اضافه کردن حلقه تکاملی به‌طور میانگین ۶۸.۷ درصد پوشش لبه بیشتری ایجاد کرد. این نتیجه نشان می‌دهد که ارزش اصلی سیستم فقط در توانایی مدل زبانی نیست، بلکه در ترکیب آن با بازخورد اجرایی و بهینه‌سازی تکراری نهفته است.

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

اهمیت پژوهش

اهمیت این پژوهش در چند سطح قابل بررسی است و می‌توان دستاوردهای آن را در سه قلمرو کلی دسته‌بندی نمود:

جمع‌بندی

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

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