آسیب‌پذیری Xray-core در تأیید گواهی؛ گزارشگر: بی‌صدا وصله شد

کاربری با نام dyhkwong که خود را گزارشگر آسیب‌پذیری معرفی می‌کند، ۱۰ مهر ۱۴۰۵ (۲ اکتبر ۲۰۲۶) در انجمن net4people نوشت Xray-core یک آسیب‌پذیری دور زدن تأیید گواهی (certificate verification bypass) را در فوریه بی‌صدا وصله کرده و به کاربران اعلامش نکرده است. باگ در گزینه pinnedPeerCertSha256 بود؛ همان گزینه‌ای که برای کار با گواهی خودامضا (self-signed) به آن تکیه می‌شود. یک وصله تکمیلی هم ۲۰ تیر (۱۱ ژوئیه) در نسخه v26.7.11 منتشر شد.

Xray-core پیاده‌سازی مرجع پروتکل‌هایی مثل VLESS و REALITY است و کلاینت‌هایی مثل v2rayN از آن به‌عنوان هسته استفاده می‌کنند. پس این خبر برای کاربران این کلاینت‌ها و مدیران سرور مهم است؛ همان‌طور که آسیب‌پذیری میکروتیک برای مدیران شبکه بود.

باگ اول: هر گواهی در زنجیره «گواهی سرور» حساب می‌شد

پروژه ۱۹ دی ۱۴۰۴ (۹ ژانویه) در کامیت 0ca1345 دو گزینه قدیمی pin را حذف کرد و pinnedPeerCertSha256 را جایگزینشان کرد. نخستین نسخه‌ای که آن را داشت، v26.1.13 بود (۲۳ دی، پیش‌انتشار). سه روز بعد کامیت 760223a تعیین کرد که با فعال بودن این گزینه، تأیید داخلی TLS در Go کنار گذاشته شود. از آن پس، تنها لایه بررسی همان منطق pin بود.

مشکل در همین منطق بود. در کد پیش از وصله، تابع verifyChain هر گواهی غیر CA را در هر جای زنجیره که هشش با مقدار pin‌شده می‌خواند، گواهی نهایی سرور (leaf) حساب می‌کرد. به نوشته گزارشگر، مهاجم مرد میانی (MITM) می‌توانست گواهی واقعی سرور را جایی در زنجیره خودش بگذارد و از سد تأیید بگذرد. کامیت 4632984 این را اصلاح کرد: حالا فقط نخستین گواهی زنجیره leaf است. این تغییر در v26.2.6، ۱۷ بهمن (۶ فوریه)، منتشر شد. برای این باگ اطلاعیه امنیتی رسمی (advisory) منتشر نشده است؛ برداشت DevNA از تاریخ کامیت‌ها و انتشارها این است که نسخه‌های v26.1.13 تا پیش از v26.2.6 در معرض بودند (در v26.1.13، به گفته گزارشگر، فقط اگر allowInsecure هم روشن بود).

باگ دوم: advisory رسمی در تیر

گزارشگر می‌گوید ۱۲ تیر (۳ ژوئیه) فهمید وصله ناقص است و آن را از راه GitHub Security Advisory گزارش کرد. advisory با شناسه GHSA-5wf9-h793-w73c ۱۰ ژوئیه (به وقت UTC) با حساب RPRX، نگه‌دارنده پروژه، منتشر شد:

وصله شرط گذاشت که pin کردن CA فقط همراه serverName (یا verifyPeerCertByName یا آدرس خروجی) پذیرفته شود.

دو روایت از یک وصله

روایت گزارشگر: باگ ۱۷ بهمن به‌طور خصوصی گزارش شد و همان روز با پیام کامیت «ساده‌سازی کد» و بدون اعلام آسیب‌پذیری وصله شد. به گفته او، چون گزینه قدیمی حذف شده بود، کاربران گواهی خودامضا ناچار به گزینه آسیب‌پذیر کوچ کردند. یادداشت انتشار v26.2.6 هم allowInsecure را حذف کرده و کاربران را به pinnedPeerCertSha256 ارجاع داده است؛ این یادداشت از آسیب‌پذیری نامی نمی‌برد، اما PR وصله را در فهرست تغییرات آورده و برای «اصلاحات مهم» به به‌روزرسانی توصیه کرده است.

آنچه سابقه عمومی مخزن نشان می‌دهد: PR شماره 5656 را یکی از توسعه‌دهندگان پروژه ۵ فوریه (به وقت UTC) باز کرد، یک روز پیش از تاریخ گزارش خصوصی به روایت گزارشگر؛ ادغامش ۶ فوریه بود. این PR پاسخ به یک باگ عمومی بود: اتصال Hysteria2 با گواهی خودامضا و pin برقرار نمی‌شد. توضیح PR می‌گوید «قبلاً کمی اشتباه شده بود؛ گواهی اول همیشه leaf است». RPRX هم ۹ فوریه در همان PR یک مسیر حمله احتمالی ناشی از این تغییر را بررسی کرد و نوشت عملی نیست، چون مهاجم کلید خصوصی CA را ندارد. باگ دوم هم یک هفته پس از گزارش، advisory عمومی گرفت. DevNA نمی‌تواند گزارش خصوصی ادعاشده را ببیند و تا زمان نگارش، نگه‌دارندگان در رشته net4people پاسخی نداده‌اند.

کاربران Xray-core همین حالا چه کنند؟

۱. نسخه را ببینید:

# print the Xray-core build version
xray version

۲. به v26.7.11 یا بالاتر بروید. آخرین نسخه هنگام نگارش v26.9.30 (۸ مهر) است. همه نسخه‌های پس از v26.3.27، از جمله v26.7.11، در صفحه انتشارها «پیش‌انتشار» علامت خورده‌اند و خود v26.3.27، آخرین نسخه پایدار، در بازه آسیب‌پذیر است.

۳. اگر هش CA را pin کرده‌اید، serverName را صریح بنویسید؛ وصله هم همین را اجباری کرد.

۴. در کلاینت‌های گرافیکی نسخه هسته Xray-core داخلی را جدا بررسی کنید؛ نسخه خود اپ ملاک نیست.

پروژه در SECURITY.md از پژوهشگران خواسته آسیب‌پذیری‌ها را خصوصی گزارش کنند. مطلب Java 27 و TLS پساکوانتومی و گزارش افشای کلیدها در مخزن‌های عمومی GitHub را هم بخوانید؛ و برای سمت دیگر همین زنجیره اعتماد، ربایش رجیستری سه ccTLD و گواهی‌های TLS غیرمجاز.