کلود در ۲۵ پروژه‌ی متن‌باز ۴۹۳ مورد پیدا کرد؛ ۴۵۰۰ خط کد قابل‌دسترسی در OpenSSH

تیم قرمز مرزی آنتروپیک این‌بار کلود را برای پیدا کردن «باگ» نفرستاد؛ مأموریت این بود که ببیند چه بخش‌هایی از کد برای مهاجم قابل‌دسترسی است، در حالی که نباید باشد. نتیجه روی ۲۵ پروژه‌ی متن‌باز، ۴۹۳ مورد بود، از جمله ناهماهنگی‌ای که ۲۱ سال در یک نرم‌افزار مانده بود.

۱. ماجرا چیست و چرا با جستجوی باگ فرق دارد؟

پژوهشگران تیم قرمز مرزی آنتروپیک معمولاً درباره‌ی پیدا کردن آسیب‌پذیری‌ها با کلود صحبت می‌کردند. این بار رویکرد عوض شده است. نویسنده‌ی اصلی متن، کریس رورف (Chris Rohlf)، توضیح می‌دهد که هدف پیدا کردن تک‌تک باگ‌ها نیست؛ هدف نقشه‌برداری از کدی است که یک استقرار واقعی عملاً در معرض دنیای بیرون می‌گذارد و سپس محدود کردن هر چیزی که آن استقرار به آن نیاز ندارد.

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

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

۲. روش کار: سه نوع تحلیل روی کد

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

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

مقیاس کار

کلود روی بیش از پنج میلیون خط کد به زبان‌های C، ++C، جاوا، PHP و پایتون کار کرد. نخست فهرستی بیش از ۱۷ هزار گزینه‌ی پیکربندی ساخت و از میان آن‌ها ۳۸۴۲ گزینه را مرتبط با امنیت تشخیص داد. جمع مواردی که در پایان گزارش شد ۴۹۳ مورد است.

۳. یافته‌های پروژه‌های دروازه‌دار

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

در عدد، کلود ۹۳ سطح غیرضروری پیش از احراز هویت در پیکربندی پیش‌فرض پیدا کرد. همچنین ۳۷ جا مشاهده شد که کد پیش از ورود کاربر اجرا می‌شد یا وضعیتی را ثبت می‌کرد. و ۶۱ ترکیب پیکربندی وجود داشت که یک کنترل پیش‌از‌ورود را که مدیر سیستم خودش تنظیم کرده بود، بی‌سروصدا ضعیف می‌کرد.

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

۴. ۱۶۲ ترکیب پیکربندی که بدون هشدار پذیرفته شد

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

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

ناهماهنگی ۲۱ ساله

یکی از موارد پیدا‌شده سابقه‌ی ۲۱ ساله داشت. دو گزینه با هم تداخل داشتند: اولی همه‌ی کلاینت‌ها را ملزم می‌کرد با گواهی هویت خود را ثابت کنند و دومی قرار بود فقط زمان این بررسی را به تعویق بیندازد، اما در عمل کل بررسی را غیرفعال می‌کرد. نتیجه این بود که سروری که باید فقط از کلاینت‌های مورد اعتماد پذیرش می‌کرد، هر کسی را می‌پذیرفت و کد پردازش درخواست در برابر کلاینت‌های احراز‌نشده در معرض بود. مستندات هم چیزی درباره‌ی حذف شدن شرط گواهی نمی‌گفت.

مورد مشابهی در حوزه‌ی TLS هم گزارش شد: الزام به گواهی کلاینت در بعضی نقطه‌های ورودی به‌دلیل تفاوت فضای نام پیکربندی بی‌سروصدا نادیده گرفته می‌شد.

۵. مطالعه‌ی موردی OpenSSH

در میان همه‌ی پروژه‌ها، بزرگ‌ترین کاهش نسبت به اندازه‌ی پروژه به OpenSSH مربوط بود. در نسخه‌ی ۱۰٫۴ حدود ۴۵۰۰ خط کد آزمایشی برای الگوریتم امضای پسا‌کوانتومی ML-DSA-44 وجود داشت که کلاینت احراز‌هویت‌نشده می‌توانست در پیکربندی پیش‌فرض به آن برسد، حتی وقتی این الگوریتم فعال نشده بود. علتش این بود که دیمن، کلید را پیش از بررسی مجاز بودن نوع آن تجزیه می‌کرد. به گفته‌ی نویسندگان، این مقدار حدود ۱۶ درصد از کد پیش‌از‌احراز‌هویت در یک sshd پیش‌فرض است.

نگهدارندگان پروژه در نسخه‌ی ۱۰٫۵ بررسی مجاز بودن را پیش از تجزیه گذاشتند. اما کلود دو شکاف دیگر پیدا کرد. اولین شکاف این بود که بررسی بر پایه‌ی نام الگوریتمی بود که کلاینت اعلام می‌کند، در حالی که تجزیه‌گر از رشته‌ی نوع داخل خودِ بلوک کلید استفاده می‌کرد. یعنی کلاینت می‌توانست نوع مجاز را اعلام کند و در عمل کلید ML-DSA بفرستد. شکاف دوم این بود که امضای مرجع صدور گواهی (CA) کنترل نمی‌شد. چون انواع گواهی به‌صورت پیش‌فرض فعال‌اند، هر تأییدکننده‌ی امضای کلید عمومی در برنامه برای هر کلاینتی که بتواند تبادل کلید را کامل کند در دسترس بود.

تیم یک اثبات مفهوم ساخت و با نگهدارندگان چند دور اصلاح را جلو برد. راه‌حل نهایی بررسی فهرست مجاز را داخل تجزیه‌گر می‌گذارد، پیش از ساخت ساختار کلید یا تأیید امضای CA. نتیجه این شد که حدود یک‌پنجم کدی که پیش‌تر برای کلاینت احراز‌هویت‌نشده در ساخت پیش‌فرض قابل‌دسترسی بود حذف شد. این تغییرها در OpenSSH 10.6 منتشر شد و یادداشت انتشار از آنتروپیک و کلود نام برده است.

جمله‌ی کلیدی نویسندگان این است که OpenSSH یکی از بیشتر ممیزی‌شده‌ترین کدهای دنیاست و اگر دسترس‌پذیری غیرضروری آنجا زنده بماند، «همه‌جا می‌تواند زنده بماند».

۶. چطور مطمئن شدند اصلاح‌ها چیزی را خراب نمی‌کند؟

خطر هر تغییر امنیتی این است که رفتار عادی نرم‌افزار را به هم بزند. تیم برای همین یک مهارت (Skill) قابل‌استفاده‌ی مجدد برای کلود ساخته که در سه گذر اجرا می‌شود. هر گذر با یک پنجره‌ی زمینه‌ی خالی و یک یادداشت کوتاه از گذر قبل شروع می‌شود تا خطاهای قبلی به گذر بعدی نشت نکند.

هر یافته با ردیابی پویای برنامه تأیید می‌شود، نه صرفاً با خواندن کد. برای دروازه‌گذاری روی پیکربندی پیش‌فرض، مجموعه‌ی آزمون خودِ پروژه و یک مجموعه‌ی آزمون جعبه‌سیاه باید نتیجه‌ی کاملاً یکسانی با نسخه‌ی پایه بدهند. تغییرهایی که پیکربندی غیرپیش‌فرض را لمس می‌کنند کنار گذاشته می‌شوند تا انسان تصمیم بگیرد. برای مواردی مثل برهم‌کنش گزینه‌ها یا دسترس‌پذیری زودهنگام، مهارت پیشنهادهایی مثل تغییر ترتیب بررسی‌ها، افزودن محافظ ترتیب وضعیت یا رد ترکیب‌های نامعتبر هنگام بارگذاری پیکربندی می‌دهد.

آنتروپیک اعلام کرده این مهارت را در ابزار OSS-Scanner خود ادغام می‌کند و در ادامه از تحلیل لاگ‌های زمان اجرا هم می‌شود برای پیدا کردن تجزیه‌گرهای بی‌استفاده، پروتکل‌های قدیمی و داشبوردهایی که می‌شود خاموششان کرد، بهره گرفت.

۷. محدودیت‌ها و نکاتی که باید محتاطانه خواند

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

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

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

۸. این خبر برای مدیران سیستم و توسعه‌دهندگان ایرانی چه معنایی دارد؟

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

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

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

۹. جایگاه این خبر در رقابت امنیت سایبری هوش مصنوعی

این پژوهش دنباله‌ی کارهای قبلی تیم قرمز مرزی است؛ از جمله گزارش فوریه‌ی ۲۰۲۶ درباره‌ی بیش از ۵۰۰ آسیب‌پذیری با شدت بالا که کلود در کتابخانه‌های متن‌باز پیدا و تأیید کرد. تفاوت این‌بار در تمرکز روی دفاع ساختاری است، نه شکار تک‌به‌تک.

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

۱۰. پرسش‌های متداول

آیا کلود در این پژوهش آسیب‌پذیری جدید پیدا کرد؟

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

آیا باید همین الان OpenSSH را به‌روزرسانی کنم؟

اصلاح‌های مرتبط در نسخه‌های ۱۰٫۵ و ۱۰٫۶ آمده است. به‌روزرسانی به آخرین نسخه‌ی پایدار توصیه‌ی عمومی امنیتی است، اما برای تصمیم دقیق، یادداشت انتشار پروژه را بخوانید.

آیا نتایج مستقل تأیید شده‌اند؟

خیر. آنتروپیک خودش می‌گوید این یک پیش‌نمایش پژوهشی با داده‌های گزارش‌شده توسط خود شرکت است و هنوز آزمایش مستقل ندارد.

این مهارت در دسترس عموم است؟

آنتروپیک اعلام کرده سه تکنیک را در یک مهارت قابل‌استفاده‌ی مجدد برای کلود جمع کرده و در حال افزودنش به OSS-Scanner است. جزئیات دسترسی عمومی در منبع اصلی ذکر نشده است.