Log4j 2 لائبریری (CVE-2021-45105) میں ایک اور خطرے کی نشاندہی کی گئی ہے، جسے، پچھلے دو مسائل کے برعکس، خطرناک کے طور پر درجہ بندی کیا گیا ہے، لیکن اہم نہیں۔ نیا مسئلہ آپ کو سروس سے انکار کرنے کی اجازت دیتا ہے اور کچھ لائنوں پر کارروائی کرتے وقت خود کو لوپس اور کریشز کی شکل میں ظاہر کرتا ہے۔ چند گھنٹے پہلے جاری کردہ Log4j 2.17 ریلیز میں خطرے کو ٹھیک کیا گیا تھا۔ خطرے کے خطرے کو اس حقیقت سے کم کیا جاتا ہے کہ مسئلہ صرف Java 8 والے سسٹمز پر ظاہر ہوتا ہے۔
کمزوری ان سسٹمز کو متاثر کرتی ہے جو لاگ آؤٹ پٹ فارمیٹ کا تعین کرنے کے لیے سیاق و سباق کے سوالات (Context Lookup) استعمال کرتے ہیں، جیسے ${ctx:var}۔ 4-alpha2.0 سے 1 تک کے Log2.16.0j ورژن میں بے قابو تکرار کے خلاف تحفظ کا فقدان تھا، جس کی وجہ سے ایک حملہ آور کو متبادل میں استعمال ہونے والی قدر میں ہیرا پھیری کرنے کا موقع ملا جس سے اسٹیک کی جگہ ختم ہو جاتی ہے اور کریش ہو جاتا ہے۔ خاص طور پر، "${${::-${::-$${::-j}}}}" جیسی اقدار کو تبدیل کرتے وقت مسئلہ پیش آیا۔
مزید برآں، یہ نوٹ کیا جا سکتا ہے کہ بلومیرا کے محققین نے کمزور جاوا ایپلی کیشنز پر حملہ کرنے کا ایک آپشن تجویز کیا ہے جو بیرونی نیٹ ورک کی درخواستوں کو قبول نہیں کرتی ہیں؛ مثال کے طور پر، جاوا ایپلی کیشنز کے ڈویلپرز یا صارفین کے سسٹمز پر اس طرح حملہ کیا جا سکتا ہے۔ طریقہ کار کا خلاصہ یہ ہے کہ اگر صارف کے سسٹم پر جاوا کے ایسے کمزور عمل ہیں جو صرف مقامی میزبان سے نیٹ ورک کنکشن قبول کرتے ہیں، یا RMI کی درخواستوں (ریموٹ میتھڈ انوکیشن، پورٹ 1099) پر کارروائی کرتے ہیں، تو حملہ جاوا اسکرپٹ کوڈ کے ذریعے کیا جا سکتا ہے۔ جب صارفین اپنے براؤزر میں ایک بدنیتی پر مبنی صفحہ کھولتے ہیں۔ اس طرح کے حملے کے دوران جاوا ایپلی کیشن کے نیٹ ورک پورٹ سے کنکشن قائم کرنے کے لیے، WebSocket API کا استعمال کیا جاتا ہے، جس پر HTTP درخواستوں کے برعکس، ایک ہی اصل کی پابندیاں لاگو نہیں ہوتی ہیں (WebSocket کو مقامی سطح پر نیٹ ورک پورٹس کو اسکین کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔ دستیاب نیٹ ورک ہینڈلرز کا تعین کرنے کے لیے میزبان)۔
لاگ 4 جے انحصار سے وابستہ لائبریریوں کی کمزوری کا اندازہ لگانے کے لیے گوگل کے شائع کردہ نتائج بھی دلچسپی کا باعث ہیں۔ گوگل کے مطابق، یہ مسئلہ ماون سینٹرل ریپوزٹری میں موجود تمام پیکجوں کے 8% کو متاثر کرتا ہے۔ خاص طور پر، براہ راست اور بالواسطہ انحصار کے ذریعے Log35863j سے وابستہ 4 جاوا پیکجز کو کمزوریوں کا سامنا کرنا پڑا۔ ایک ہی وقت میں، Log4j کو صرف 17% معاملات میں براہ راست پہلی سطح کے انحصار کے طور پر استعمال کیا جاتا ہے، اور 83% متاثرہ پیکجوں میں، بائنڈنگ انٹرمیڈیٹ پیکجوں کے ذریعے کی جاتی ہے جو Log4j پر منحصر ہوتے ہیں، یعنی دوسرے اور اعلی درجے کی لت (21% - دوسری سطح، 12% - تیسری، 14% - چوتھی، 26% - پانچویں، 6% - چھٹی)۔ خطرے کو دور کرنے کی رفتار اب بھی مطلوبہ بہت کچھ چھوڑ دیتی ہے؛ خطرے کی نشاندہی کے ایک ہفتے بعد، 35863 شناخت شدہ پیکجوں میں سے، اب تک صرف 4620 میں مسئلہ حل کیا گیا ہے، یعنی 13 فیصد پر۔
دریں اثنا، یو ایس سائبرسیکیوریٹی اور انفراسٹرکچر پروٹیکشن ایجنسی نے ایک ہنگامی ہدایت جاری کی جس میں وفاقی ایجنسیوں سے مطالبہ کیا گیا کہ وہ Log4j کے خطرے سے متاثر ہونے والے انفارمیشن سسٹمز کی نشاندہی کریں اور 23 دسمبر تک اس مسئلے کو روکنے والی اپ ڈیٹس انسٹال کریں۔ 28 دسمبر تک تنظیموں کو اپنے کام کی رپورٹ دینا ہوگی۔ مسائل والے نظاموں کی شناخت کو آسان بنانے کے لیے، ان مصنوعات کی فہرست تیار کی گئی ہے جن کی کمزوریوں کو ظاہر کرنے کی تصدیق کی گئی ہے (فہرست میں 23 ہزار سے زیادہ درخواستیں شامل ہیں)۔
ماخذ: opennet.ru