خودداری مدل‌های هوش مصنوعی بسته از تحلیل باگ لینوکس؛ پناه بردن محققان به مدل‌های وزن‌باز

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

دنیل فاکس فرانکه (Daniel Fox Franke)، محقق حوزه امنیت، اخیراً در تلاش بود تا ریشه خطای حافظه (Segmentation Fault) در ابزار ripgrep را پیدا کند؛ اما متوجه شد مدل GPT-5.6 Sol شرکت اوپن‌ای‌آی حاضر به همکاری با او نیست.

او در پستی در شبکه‌های اجتماعی نوشت: «سیستم طبقه‌بندی امنیت سایبری اوپن‌ای‌آی هنگام تلاش برای ردیابی یک خطای سگفالت (Segfault)، دردسر بزرگی ایجاد می‌کند... این غربالگر امنیتی حتی اجازه نمی‌دهد مدل پاسخ دهد که کدام نقطه‌های ورودی از ابزار rg به کتابخانه musl به تخصیص حافظه در هیپ mallocng ختم می‌شوند.»

درست مانند اتفاقی که پیش‌تر برای هاگینگ فیس رخ داد، فرانکه نیز در نهایت مجبور شد برای تکمیل تحلیل و گزارش خود درباره آنچه باگ کرنل لینوکس به نظر می‌رسد، به مدل‌های وزن‌باز توسعه‌دهندگان چینی، یعنی GLM 5.2 از شرکت Zhipu AI و Kimi K3 از استارتاپ Moonshot AI پناه ببرد.

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

«تنها چند دقیقه بعد با اولین خطای سیستم طبقه‌بندی امنیتی مواجه شدم؛ ایجنت اصلی به من اطلاع داد که ساب‌ایجنت مسیری نامناسب را برای تحقیق در پیش گرفته است و تلاش می‌کند آن را به مسیر دیگری هدایت کند.»

با این حال به گفته او، سیستم غربالگری امنیتی چندین بار پشت سر هم از پردازش درخواست سر باز زد.

او توضیح داد: «به نظر می‌رسید تلاش برای بازتولید کرش و تحلیل وضعیت هیپ (حافظه موقت) عامل اصلی این هشدارها بود. به همین دلیل یک پنجره زمینه (کانتکست) جدید باز کردم و در آن تذکر دادم که چنین خطاهایی رخ داده و وظیفه مدل باید دقیقاً به تحلیل کدهای سورس ripgrep و musl محدود شود (نه کرنل، زیرا در آن زمان اصلاً تصوری از اینکه مشکل از هسته لینوکس باشد نداشتم)؛ همچنین مدل نباید تلاشی برای بازتولید خطا یا بررسی فایل‌های Core انجام دهد. با وجود رعایت این دستورالعمل‌ها، فیلتر امنیتی همچنان مداخله می‌کرد و پیام خطا می‌داد؛ همین‌جا بود که از دریافت پاسخی کاربردی از این ابزار قطع امید کردم.»

فرانکه اشاره کرد با توجه به اینکه مدل‌های شرکت آنتروپیک سخت‌گیری‌های به‌مراتب شدیدتری اعمال می‌کنند، حتی به سراغ آزمایش اعضای خانواده مدل‌های کلود (Claude) نیز نرفته است.

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

به گفته فرانکه، اگرچه پیام‌های خطای اوپن‌ای‌آی او را به برنامه «دسترسی موثق سازمانی» (Enterprise Trusted Access) راهنمایی می‌کردند، اما او برای آن ثبت‌نام نکرد چون شرایط لازم را نداشت. او بیان کرد تا همین اواخر متوجه نشده بود که برنامه دسترسی موثق جداگانه‌ای برای افراد حقیقی نیز وجود دارد.

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

دو مدل باز در این فرآیند شکار باگ کارآمدی خود را ثابت کردند: GLM 5.2 و Kimi K3. فرانکه اظهار داشت که هر یک از آن‌ها وظیفه مشخص و متفاوتی را به انجام رساندند.

او گفت: «مدل K3 موفقیت اولیه را رقم زد و سرنخ کلیدی مبنی بر مواجهه با یک باگ در هسته سیستم‌عامل را پیدا کرد، اما روند تحقیقاتی بعدی آن بسیار شلخته و بی‌دقت بود؛ نتیجه‌گیری‌های بی‌اساس می‌کرد، اسناد و مدارک خودش را مخدوش می‌ساخت و با بزرگ‌تر شدن طول کانتکست (پنجره زمینه)، به‌طور کامل از مسیر اصلی خارج شد. در مقابل، مدل GLM 5.2 کار را برایم تمام کرد؛ یافته‌های K3 را مجدداً ارزیابی و بازبینی کرد و یک پرونده مستدل و بی‌نقص تحویل داد.»

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

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

این کارشناس امنیت یادآور شد که پرونده این باگ لینوکس هنوز به پایان نرسیده است؛ این مشکل در حال حاضر پچ اصلاحی ندارد، هرچند به نظر نمی‌رسد نشان‌دهنده یک آسیب‌پذیری با قابلیت سوءاستفاده امنیتی باشد.

او گفت: «در وضعیت فعلی تحقیقات، دو موضوع را با قطعیت می‌دانم؛ اول اینکه این کرش‌ها به دلیل یک باگ در کرنل رخ می‌دهند و دوم اینکه باگ کرنل را شناسایی کرده‌ام. اما اینکه دقیقاً همین باگ عامل کرش‌ها باشد هنوز در حد یک فرضیه است و قبل از آنکه بتوانم گزارشی برای لیست ایمیل‌های توسعه‌دهندگان هسته لینوکس (LKML) بفرستم، باید تحقیقات بسیار بیشتری انجام دهم.»

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