آسیب پذیری دیگری در کتابخانه Log4j 2 (CVE-2021-45105) شناسایی شده است که بر خلاف دو مشکل قبلی، به عنوان خطرناک طبقه بندی می شود، اما حیاتی نیست. شماره جدید به شما امکان می دهد تا باعث انکار سرویس شوید و در هنگام پردازش خطوط خاص خود را به شکل حلقه ها و خرابی ها نشان می دهد. این آسیب پذیری در نسخه Log4j 2.17 که ساعاتی پیش منتشر شد برطرف شد. خطر آسیب پذیری با این واقعیت کاهش می یابد که این مشکل فقط در سیستم هایی با جاوا 8 ظاهر می شود.
این آسیب پذیری سیستم هایی را تحت تأثیر قرار می دهد که از پرس و جوهای متنی (Context Lookup)، مانند ${ctx:var} برای تعیین فرمت خروجی گزارش استفاده می کنند. نسخه های Log4j از 2.0-alpha1 تا 2.16.0 فاقد محافظت در برابر بازگشت کنترل نشده بودند، که به مهاجم اجازه می داد مقدار استفاده شده در جایگزینی را دستکاری کند تا یک حلقه ایجاد کند، که منجر به تخلیه فضای پشته و خرابی شود. به طور خاص، این مشکل هنگام جایگزینی مقادیری مانند "${${::-${::-$${::-j}}}} رخ داد.
علاوه بر این، می‌توان اشاره کرد که محققان Blumira گزینه‌ای را برای حمله به برنامه‌های کاربردی آسیب‌پذیر جاوا که درخواست‌های شبکه خارجی را قبول نمی‌کنند پیشنهاد کرده‌اند؛ برای مثال، سیستم‌های توسعه‌دهندگان یا کاربران برنامه‌های جاوا را می‌توان از این طریق مورد حمله قرار داد. ماهیت روش این است که اگر فرآیندهای جاوا آسیب‌پذیری روی سیستم کاربر وجود داشته باشد که اتصالات شبکه را فقط از میزبان محلی می‌پذیرد، یا درخواست‌های RMI را پردازش می‌کند (Remote Method Invocation، پورت 1099)، حمله می‌تواند توسط کد جاوا اسکریپت اجرا شده انجام شود. هنگامی که کاربران یک صفحه مخرب را در مرورگر خود باز می کنند. برای ایجاد اتصال به پورت شبکه یک برنامه جاوا در طول چنین حمله‌ای، از WebSocket API استفاده می‌شود که بر خلاف درخواست‌های HTTP، محدودیت‌های همان مبدأ اعمال نمی‌شود (WebSocket همچنین می‌تواند برای اسکن پورت‌های شبکه در محلی استفاده شود. میزبان به منظور تعیین کنترل کننده های شبکه موجود).
همچنین نتایج منتشر شده توسط گوگل در مورد ارزیابی آسیب پذیری کتابخانه های مرتبط با وابستگی های Log4j قابل توجه است. به گفته گوگل، این مشکل 8 درصد از تمام بسته های موجود در مخزن مرکزی Maven را تحت تاثیر قرار می دهد. به طور خاص، 35863 بسته جاوا مرتبط با Log4j از طریق وابستگی های مستقیم و غیرمستقیم در معرض آسیب پذیری قرار گرفتند. در عین حال، Log4j به عنوان یک وابستگی مستقیم سطح اول فقط در 17٪ موارد استفاده می شود و در 83٪ از بسته های آسیب دیده، اتصال از طریق بسته های میانی انجام می شود که به Log4j وابسته هستند، یعنی. اعتیادهای سطح دوم و بالاتر (21٪ - سطح دوم، 12٪ - سوم، 14٪ - چهارم، 26٪ - پنجم، 6٪ - ششم). سرعت رفع آسیب‌پذیری هنوز جای تامل دارد؛ یک هفته پس از شناسایی آسیب‌پذیری، از 35863 بسته شناسایی شده، این مشکل تاکنون تنها در 4620 بسته برطرف شده است. در 13 درصد
در همین حال، آژانس امنیت سایبری و حفاظت از زیرساخت ایالات متحده دستور اضطراری را صادر کرد که در آن آژانس‌های فدرال را ملزم می‌کرد تا سیستم‌های اطلاعاتی تحت تأثیر آسیب‌پذیری Log4j را شناسایی کرده و به‌روزرسانی‌هایی را نصب کنند که مشکل را تا 23 دسامبر مسدود می‌کند. تا 28 دسامبر، سازمان ها موظفند در مورد کار خود گزارش دهند. برای ساده‌سازی شناسایی سیستم‌های مشکل‌ساز، فهرستی از محصولاتی که تأیید شده‌اند آسیب‌پذیری را نشان می‌دهند تهیه شده است (لیست شامل بیش از 23 هزار برنامه است).
منبع: opennet.ru