কিছুদিন আগে সেই খবর প্রকাশিত হয়েছিল সি স্ট্যান্ডার্ড লাইব্রেরিতে uClibc এবং uClibc-ng, অনেক এমবেডেড এবং বহনযোগ্য ডিভাইসে ব্যবহৃত, একটি দুর্বলতা চিহ্নিত করা হয়েছে (CVE এখনও বরাদ্দ করা হয়নি), যা DNS ক্যাশে ডামি ডেটা প্রতিস্থাপনের অনুমতি দেয়, যা ক্যাশে একটি নির্বিচারে ডোমেনের আইপি ঠিকানা স্পুফ করতে এবং আক্রমণকারীর সার্ভারে ডোমেনে অনুরোধগুলি পুনঃনির্দেশ করতে ব্যবহার করা যেতে পারে।
সমস্যা সম্পর্কে উল্লেখ করা হয় যে এই রাউটার, অ্যাক্সেস পয়েন্ট এবং আইওটি ডিভাইসের জন্য বিভিন্ন লিনাক্স ফার্মওয়্যারকে প্রভাবিত করে, পাশাপাশি ওপেনডব্লিউআরটি এবং এমবেডেড জেন্টু-এর মতো এমবেডেড লিনাক্স ডিস্ট্রিবিউশন।
দুর্বলতা সম্পর্কে
ক্ষতিগ্রস্থতা প্রশ্ন পাঠানোর জন্য কোডে অনুমানযোগ্য লেনদেন শনাক্তকারী ব্যবহারের কারণে DNS এর। DNS ক্যোয়ারী আইডিটি পোর্ট নম্বরের আরও এলোমেলোকরণ ছাড়াই কেবল কাউন্টার বৃদ্ধি করে বেছে নেওয়া হয়েছিল, যা এটি ডিএনএস ক্যাশে বিষাক্ত করা সম্ভব করেছে জাল প্রতিক্রিয়া সহ UDP প্যাকেটগুলি আগাম প্রেরণ করে (প্রতিক্রিয়াটি গ্রহণ করা হবে যদি এটি প্রকৃত সার্ভার থেকে প্রতিক্রিয়ার আগে আসে এবং সঠিক সনাক্তকরণ অন্তর্ভুক্ত করে)।
2008 সালে প্রস্তাবিত কামিনস্কি পদ্ধতির বিপরীতে, লেনদেন আইডি অনুমান করারও প্রয়োজন নেই, যেহেতু এটি প্রাথমিকভাবে অনুমানযোগ্য (প্রাথমিকভাবে, এটি 1 এ সেট করা হয়, যা প্রতিটি অনুরোধের সাথে বৃদ্ধি পায় এবং এলোমেলোভাবে নির্বাচিত হয় না)।
নিজেকে রক্ষা করতে আইডি অনুমান, স্পেসিফিকেশন বিরুদ্ধে আরও সুপারিশ করে নেটওয়ার্ক পোর্ট নম্বরের র্যান্ডম ডিস্ট্রিবিউশন ব্যবহারের মূল যেখান থেকে DNS প্রশ্ন পাঠানো হয়, যা আইডির অপর্যাপ্ত আকারের জন্য ক্ষতিপূরণ দেয়।
যখন পোর্ট র্যান্ডমাইজেশন সক্ষম করা হয়, তখন একটি ডামি প্রতিক্রিয়া তৈরি করতে, একটি 16-বিট শনাক্তকারী নির্বাচন করার পাশাপাশি, নেটওয়ার্ক পোর্ট নম্বরটিও নির্বাচন করা প্রয়োজন৷ uClibc এবং uClibc-ng-এ, এই ধরনের র্যান্ডমাইজেশন স্পষ্টভাবে সক্রিয় করা হয়নি (যখন বাইন্ড বলা হয়েছিল, একটি র্যান্ডম সোর্স UDP পোর্ট নির্দিষ্ট করা হয়নি) এবং এর বাস্তবায়ন অপারেটিং সিস্টেম কনফিগারেশনের উপর নির্ভর করে।
যখন পোর্ট র্যান্ডমাইজেশন অক্ষম করা হয়, কোন রিকোয়েস্ট আইডি বাড়াতে হবে তা নির্ধারণ করা একটি তুচ্ছ কাজ হিসেবে চিহ্নিত. কিন্তু এমনকি র্যান্ডমাইজেশনের ক্ষেত্রেও, আক্রমণকারীকে কেবলমাত্র 32768-60999 রেঞ্জ থেকে নেটওয়ার্ক পোর্ট অনুমান করতে হবে, যার জন্য সে বিভিন্ন নেটওয়ার্ক পোর্টে ডামি প্রতিক্রিয়াগুলির বিশাল একযোগে প্রেরণ ব্যবহার করতে পারে।
সমস্যা uClibc এবং uClibc-ng এর সমস্ত বর্তমান সংস্করণে নিশ্চিত করা হয়েছে, uClibc 0.9.33.2 এবং uClibc-ng 1.0.40 এর সর্বশেষ সংস্করণ সহ।
"এটি লক্ষ্য করা গুরুত্বপূর্ণ যে একটি স্ট্যান্ডার্ড সি লাইব্রেরিকে প্রভাবিত করে এমন একটি দুর্বলতা বেশ জটিল হতে পারে," দলটি এই সপ্তাহে একটি ব্লগ পোস্টে লিখেছিল।
"শুধুমাত্র একটি প্রোগ্রামের একাধিক পয়েন্টে দুর্বল ফাংশনে শত শত বা হাজার হাজার কল থাকবে না, তবে দুর্বলতা সেই লাইব্রেরিটি ব্যবহার করার জন্য কনফিগার করা অন্যান্য বহু-বিক্রেতা প্রোগ্রামগুলির একটি অনির্দিষ্ট সংখ্যক প্রভাবিত করবে।"
2021 সালের সেপ্টেম্বরে, দুর্বলতা সম্পর্কে তথ্য পাঠানো হয়েছিল সমন্বিত অ্যারে প্রস্তুতির জন্য CERT/CC-তে। 2022 সালের জানুয়ারিতে, সমস্যাটি 200 টিরও বেশি নির্মাতার সাথে ভাগ করা হয়েছিল CERT/CC এর সাথে যুক্ত।
মার্চ মাসে, uClibc-ng প্রকল্পের রক্ষণাবেক্ষণকারীর সাথে আলাদাভাবে যোগাযোগ করার চেষ্টা করা হয়েছিল, কিন্তু তিনি উত্তর দিয়েছিলেন যে তিনি নিজেই দুর্বলতা ঠিক করতে পারেননি এবং সমস্যার সমাধানের জন্য সাহায্য পাওয়ার আশায়, সমস্যা সম্পর্কে তথ্য প্রকাশের সুপারিশ করেছিলেন। সম্প্রদায়. নির্মাতাদের কাছ থেকে, NETGEAR দুর্বলতা অপসারণের সাথে একটি আপডেট প্রকাশের ঘোষণা করেছে।
এটি লক্ষ করা গুরুত্বপূর্ণ যে একটি স্ট্যান্ডার্ড সি লাইব্রেরি প্রভাবিত একটি দুর্বলতা বেশ জটিল হতে পারে। শুধুমাত্র একক প্রোগ্রামের একাধিক পয়েন্টে দুর্বল ফাংশনে শত শত বা হাজার হাজার কল হবে না, তবে দুর্বলতা সেই লাইব্রেরিটি ব্যবহার করার জন্য কনফিগার করা একাধিক বিক্রেতাদের থেকে অনির্দিষ্ট সংখ্যক অন্যান্য প্রোগ্রামকে প্রভাবিত করবে।
এটি উল্লেখ করা হয়েছে যে দুর্বলতা অনেক নির্মাতার ডিভাইসে নিজেকে প্রকাশ করে (উদাহরণস্বরূপ, লিংকসিস, নেটগিয়ার এবং অ্যাক্সিসের ফার্মওয়্যারে uClibc ব্যবহার করা হয়), কিন্তু যেহেতু দুর্বলতাটি uClibc এবং uClibc-ng-এ অপরিবর্তিত থাকে, তাই ডিভাইস সম্পর্কে বিস্তারিত তথ্য এবং নির্দিষ্ট নির্মাতারা যাদের পণ্যে সমস্যা আছে, যতক্ষণ না তারা প্রকাশ করা হয়।
পরিশেষে আপনি যদি এটি সম্পর্কে আরও জানতে আগ্রহী হন, আপনি বিশদ পরীক্ষা করতে পারেন নীচের লিঙ্কে।