Log4j 2-এ আরেকটি দুর্বলতা। Log4j-এর সমস্যাগুলি মাভেন প্যাকেজের 8% প্রভাবিত করে

Log4j 2 লাইব্রেরিতে একটি নতুন দুর্বলতা (CVE-2021-45105) আবিষ্কৃত হয়েছে। পূর্ববর্তী দুটি সমস্যার মতো নয়, এটিকে বিপজ্জনক হিসেবে শ্রেণীবদ্ধ করা হলেও গুরুতর হিসেবে নয়। এই নতুন সমস্যাটি ডিনায়াল অফ সার্ভিস (DoS) আক্রমণের সুযোগ করে দেয় এবং নির্দিষ্ট কিছু স্ট্রিং প্রসেস করার সময় এটি একটি লুপ ও ক্র্যাশ হিসেবে প্রকাশ পায়। কয়েক ঘণ্টা আগে প্রকাশিত Log4j 2.17 সংস্করণে দুর্বলতাটি সমাধান করা হয়েছে। দুর্বলতাটির তীব্রতা এই কারণে কিছুটা কম যে, এটি শুধুমাত্র জাভা ৮ চালিত সিস্টেমগুলোকেই প্রভাবিত করে।

এই দুর্বলতাটি সেইসব সিস্টেমকে প্রভাবিত করে, যেগুলো লগ আউটপুট ফরম্যাট নির্ধারণ করতে ${ctx:var} এর মতো কনটেক্সট লুকআপ কোয়েরি (CLO) ব্যবহার করে। Log4j-এর 2.0-alpha1 থেকে 2.16.0 সংস্করণগুলোতে অনিয়ন্ত্রিত রিকারশনের বিরুদ্ধে সুরক্ষার অভাব ছিল, যার ফলে একজন আক্রমণকারী সাবস্টিটিউশনে ব্যবহৃত মান পরিবর্তন করে একটি লুপ তৈরি করতে পারত, যা স্ট্যাক এক্সহশন এবং প্রসেস ক্র্যাশের কারণ হতো। বিশেষত, "${${::-${::-$${::-j}}}}" এর মতো মান সাবস্টিটিউট করার সময় এই সমস্যাটি দেখা দিত।

এছাড়াও, ব্লুমিরার গবেষকরা এমন দুর্বল জাভা অ্যাপ্লিকেশনগুলোর ওপর আক্রমণের প্রস্তাব দিয়েছেন যেগুলো বাইরের নেটওয়ার্ক অনুরোধ গ্রহণ করে না। উদাহরণস্বরূপ, এটি জাভা অ্যাপ্লিকেশন ডেভেলপার বা ব্যবহারকারীদের সিস্টেমে আক্রমণ করার জন্য ব্যবহার করা যেতে পারে। এই পদ্ধতির মূল বিষয়টি হলো, যদি কোনো ব্যবহারকারীর সিস্টেমে এমন দুর্বল জাভা প্রসেস থাকে যা শুধুমাত্র লোকালহোস্ট থেকে নেটওয়ার্ক সংযোগ গ্রহণ করে বা আরএমআই (রিমোট মেথড ইনভোকেশন, পোর্ট ১০৯৯) অনুরোধ পরিচালনা করে, তবে ব্যবহারকারী যখন তার ব্রাউজারে একটি ক্ষতিকারক পৃষ্ঠা খোলে, তখন জাভাস্ক্রিপ্ট কোড কার্যকর করে এই আক্রমণটি চালানো যেতে পারে। জাভা অ্যাপ্লিকেশনটির নেটওয়ার্ক পোর্টে সংযোগ স্থাপন করার জন্য, এই আক্রমণটি ওয়েবসকেট এপিআই (WebSocket API) ব্যবহার করে, যা এইচটিটিপি (HTTP) অনুরোধের মতো সেম-অরিজিন সীমাবদ্ধতার অধীন নয়। (ওয়েবসকেট লোকালহোস্টের নেটওয়ার্ক পোর্ট স্ক্যান করে বিদ্যমান নেটওয়ার্ক হ্যান্ডলার শনাক্ত করতেও ব্যবহার করা যেতে পারে।)

এছাড়াও, গুগল কর্তৃক প্রকাশিত Log4j-নির্ভরশীল লাইব্রেরিগুলোর দুর্বলতা মূল্যায়নের ফলাফলও আগ্রহের বিষয়। গুগলের মতে, এই সমস্যাটি Maven Central রিপোজিটরির সমস্ত প্যাকেজের ৮%-কে প্রভাবিত করে। নির্দিষ্টভাবে বলতে গেলে, এই দুর্বলতাটি Log4j-এর উপর প্রত্যক্ষ ও পরোক্ষ নির্ভরশীল ৩৫,৮৬৩টি জাভা প্যাকেজকে প্রভাবিত করেছে। মাত্র ১৭% ক্ষেত্রে Log4j একটি সরাসরি প্রথম-স্তরের নির্ভরতা হিসেবে ব্যবহৃত হয়, যেখানে ৮৩% ঝুঁকিপূর্ণ প্যাকেজে, এই সংযোগটি Log4j-এর উপর নির্ভরশীল মধ্যবর্তী প্যাকেজগুলোর মাধ্যমে সম্পন্ন করা হয়, অর্থাৎ দ্বিতীয়-স্তর এবং তার উপরের স্তরের নির্ভরতার মাধ্যমে (২১% দ্বিতীয়-স্তরের, ১২% তৃতীয়-স্তরের, ১৪% চতুর্থ-স্তরের, ২৬% পঞ্চম-স্তরের এবং ৬% ষষ্ঠ-স্তরের)। দুর্বলতা সংশোধনের হার এখনও হতাশাজনক: দুর্বলতাটি শনাক্ত হওয়ার এক সপ্তাহ পরেও, এখন পর্যন্ত শনাক্তকৃত ৩৫,৮৬৩টি প্যাকেজের মধ্যে মাত্র ৪,৬২০টিতে, অর্থাৎ ১৩%-এ, সমস্যাটি সমাধান করা হয়েছে।

এদিকে, মার্কিন সাইবারসিকিউরিটি অ্যান্ড ইনফ্রাস্ট্রাকচার সিকিউরিটি এজেন্সি একটি জরুরি নির্দেশিকা জারি করেছে, যেখানে ফেডারেল সংস্থাগুলোকে Log4j দুর্বলতার ঝুঁকিতে থাকা তথ্য ব্যবস্থাগুলো শনাক্ত করতে এবং ২৩ ডিসেম্বরের মধ্যে সমস্যাটি সমাধানের জন্য প্যাচ ইনস্টল করার নির্দেশ দেওয়া হয়েছে। সংস্থাগুলোকে ২৮ ডিসেম্বরের মধ্যে তাদের অগ্রগতির প্রতিবেদন জমা দিতে হবে। ক্ষতিগ্রস্ত সিস্টেমগুলো শনাক্তকরণ সহজ করার জন্য, এই দুর্বলতার জন্য পণ্যগুলোর (২৩,০০০-এর বেশি অ্যাপ্লিকেশন) একটি তালিকা প্রস্তুত করা হয়েছে।

উত্স: opennet.ru