شکستن پیوند هویت و انتقال
Red Hat نقصی در WildFly گزارش کرده که در آن رهگیر امنیتی CSIv2، ادعای هویت ITTPrincipalName را بدون بررسی احراز هویت در لایهٔ انتقال می‌پذیرد. مهاجم راه دور پیش از احراز هویت می‌تواند در فراخوانی EJBهای دارای رابط Remote که از طریق IIOP ارائه شده‌اند، خود را به جای هویت دیگری معرفی کند. رکورد رسمی پورت 3528 را برای این سناریو ذکر می‌کند؛ در استقرار واقعی نگاشت پورت و مسیر دسترسی نیز باید بررسی شود.
وجود WildFly به تنهایی اثبات مواجهه نیست. لازم است شنوندهٔ IIOP، ارائهٔ EJB از این مسیر و دسترسی شبکه به آن بررسی شوند. برنامه‌ای که فقط از مسیرهای دیگر خدمت می‌دهد ممکن است شرایط متفاوتی داشته باشد. همچنین پذیرفته شدن نام هویت در پیام، با اثبات مالکیت آن هویت تفاوت دارد؛ این جداسازی همان مرزی است که نقص بر آن اثر می‌گذارد.
وضعیت محصولات در دادهٔ رسمی
رکورد CNA، بستهٔ wildfly-iiop-openjdk در JBoss EAP 8 را متأثر و EAP Expansion Pack را غیرمتأثر ثبت کرده است. وضعیت چند مؤلفه در Fuse 7، EAP 7 و Single Sign-On 7 نامشخص درج شده است. نامشخص بودن را نباید به «امن» یا «قطعاً آسیب‌پذیر» تبدیل کرد. در دادهٔ بررسی‌شده شمارهٔ دقیق بستهٔ اصلاح‌شده ارائه نشده و باید اطلاعیهٔ محصول و پاسخ پشتیبانی را پیگیری کرد.
Red Hat شدت محصولی Moderate و امتیاز CVSS 3.1 برابر 7.4 را ثبت کرده است. این دو نظام برچسب‌گذاری الزاماً یکسان نیستند. بردار رسمی پیچیدگی حمله را بالا می‌داند و پیامد تأییدشده بر محرمانگی و یکپارچگی است؛ برای این رکورد نباید از روی شباهت به آسیب‌پذیری‌های دیگر، اختلال سرویس یا اجرای کد قطعی اضافه کرد.
تعیین مواجهه و کنترل موقت
پیشنهاد تحریریه این است که تیم برنامه و تیم زیرساخت مشترکاً فهرست EJBهای ارائه‌شده از IIOP را تهیه کنند. بررسی تنها دیوارهٔ آتش کافی نیست، چون هویت‌های قابل جعل و عملیات مجاز هر EJB تعیین می‌کنند پیامد تجاری چه خواهد بود. حساب سرویس و نقش‌های مدیریتی حساس باید در ارزیابی دامنهٔ دسترسی مورد توجه باشند.
اگر IIOP استفاده نمی‌شود، غیرفعال‌سازی شنونده را طبق راهنمای محصول بررسی کنید. اگر لازم است، دسترسی آن را به همتایان مشخص محدود کنید و پیکربندی احراز هویت انتقال را با راهنمای سازنده تطبیق دهید. این اقدامات کنترل جبرانی‌اند و نباید به عنوان اثبات رفع نقص کد ثبت شوند. شمارهٔ پورت پیش‌فرض به تنهایی معیار کافی برای قواعد شبکه نیست؛ ترجمهٔ پورت و توازن بار ممکن است مسیر دیگری بسازند.
اصلاح و آزمون اعتماد
پس از انتشار یا دریافت بستهٔ مناسب، آزمون فراخوانی عادی را با هویت معتبر و آزمون رد درخواست فاقد اثبات هویت اجرا کنید. آزمایش باید مرز انتقال و نقش برنامه را هم‌زمان پوشش دهد. ثبت موفقیت صرف اتصال به سرویس، صحت کنترل هویت را نشان نمی‌دهد.
در بررسی گذشته، ادعاهای هویتی غیرمنتظره، عملیات حساس و منشأ شبکه را کنار هم ببینید. نام ثبت‌شده در لاگ برنامه ممکن است همان ادعای پذیرفته‌شده باشد؛ آن را بدون تطبیق با شواهد انتقال، هویت قطعی عامل ندانید. پروندهٔ اصلاح باید وضعیت بسته، پاسخ سازنده و نتیجهٔ آزمون هر شنوندهٔ فعال را شامل شود.
امتیاز و منابع
امتیاز ثبت‌شدهٔ CNA برابر 7.4 در CVSS 3.1 است. منبع امتیاز: redhat. بردار رسمی: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. این امتیاز ادعای وقوع حمله یا حضور در فهرست KEV نیست.
- رکورد رسمی برنامهٔ CVE
- دادهٔ رسمی CNA؛ redhat
- مرجع اولیهٔ معرفی‌شده توسط CNA
- مرجع اولیهٔ معرفی‌شده توسط CNA
تصویر همراه نشان Red Hat است و برای معرفی محصول یا سازنده استفاده می‌شود؛ تصویر حمله یا تأیید این گزارش توسط صاحب نشان نیست. بازبینی: ۲۹ اکتبر ۲۰۲۶.
