Glibc অরোরা ওএস ডেভেলপারদের দ্বারা প্রস্তুত করা memcpy দুর্বলতার জন্য একটি সমাধান অন্তর্ভুক্ত করে

অরোরা মোবাইল অপারেটিং সিস্টেমের (ওপেন মোবাইল প্ল্যাটফর্ম কোম্পানি দ্বারা নির্মিত সেলফিশ ওএস-এর একটি ফর্ক) ডেভেলপাররা নির্মূল করার বিষয়ে একটি দৃষ্টান্তমূলক গল্প শেয়ার করেছেন। সমালোচনামূলক দুর্বলতা (জন্য CVE-2020-6096Glibc-তে একটি দুর্বলতা, যা শুধুমাত্র ARMv7 প্ল্যাটফর্মে দেখা যায়। দুর্বলতাটি মে মাসে প্রকাশ করা হলেও, সম্প্রতি পর্যন্ত এর কোনো সমাধান পাওয়া যায়নি। বরাদ্দ উচ্চ মাত্রার বিপদ এবং একটি এক্সপ্লয়েটের কার্যকরী প্রোটোটাইপ যা memcpy() এবং memmove() ফাংশনগুলিতে বিশেষ ফরম্যাটের ডেটা প্রসেস করার সময় কোড এক্সিকিউশনের সুযোগ দেয়। প্যাকেজের ত্রুটি সংশোধন। Debian и Ubuntu এখনও প্রকাশ করা হয়নি এবং জনসমক্ষে প্রকাশের প্রায় দুই মাস পর ও Glibc ডেভেলপারদের অবহিত করার পাঁচ মাস পরেও দুর্বলতাটি সমাধান করা হয়নি।

ARMv7-এর জন্য memcpy() এবং memmove() ফাংশনের অ্যাসেম্বলি ল্যাঙ্গুয়েজ ইমপ্লিমেন্টেশনে এই দুর্বলতাটি প্রকাশ পায় এবং এর কারণ ছিল কপি করা এলাকার আকার নির্ধারণকারী প্যারামিটারের ঋণাত্মক মানগুলোর ভুল ব্যবস্থাপনা। প্যাচ তৈরির সমস্যা শুরু হয় যখন কোম্পানিগুলো SUSE и লাল টুপি তারা তাদের প্ল্যাটফর্মগুলোকে এই সমস্যা থেকে মুক্ত বলে ঘোষণা করেছে, কারণ তারা ৩২-বিট ARMv7 সিস্টেমের জন্য বিল্ড তৈরি করে না, এবং প্যাচটিতে অবদান রাখতে অস্বীকৃতি জানিয়েছে। অনেক এমবেডেড ডিস্ট্রিবিউশনের ডেভেলপাররা দৃশ্যত Glibc টিমের উপর নির্ভর করেছিল এবং তারাও প্যাচটিতে সক্রিয়ভাবে অবদান রাখেনি।

পছন্দ প্যাচ সমস্যাটি সমাধানের জন্য হুয়াওয়ে প্রায় সঙ্গে সঙ্গেই একটি প্রস্তাব দেয়, যেখানে তারা সাইনড অপারেন্ড (bge এবং blt) হ্যান্ডেল করে এমন অ্যাসেম্বলি ইনস্ট্রাকশনগুলোকে আনসাইনড সমতুল্য (blo এবং bhs) দিয়ে প্রতিস্থাপন করার চেষ্টা করে। Glibc-এর রক্ষণাবেক্ষণকারীরা বিভিন্ন ত্রুটি পরীক্ষা করার জন্য একগুচ্ছ টেস্ট তৈরি করেন, যার পরে এটি স্পষ্ট হয়ে যায় যে হুয়াওয়ের প্যাচটি অনুপযুক্ত ছিল এবং এটি সম্ভাব্য সমস্ত ইনপুট ডেটা সংমিশ্রণ হ্যান্ডেল করতে পারছিল না।

যেহেতু অরোরা ওএস-এর এআরএম (ARM)-এর জন্য একটি ৩২-বিট বিল্ড রয়েছে, তাই এর ডেভেলপাররা নিজেরাই দুর্বলতাটি প্যাচ করার এবং কমিউনিটির কাছে একটি সমাধান পৌঁছে দেওয়ার সিদ্ধান্ত নেন। চ্যালেঞ্জটি ছিল বিভিন্ন ইনপুট আর্গুমেন্ট বিবেচনা করে ফাংশনটির একটি কার্যকর অ্যাসেম্বলি ইমপ্লিমেন্টেশন লেখা। ইমপ্লিমেন্টেশনটি আনসাইনড ইনস্ট্রাকশন ব্যবহার করে পুনরায় লেখা হয়েছিল। তালি দেখা গেল এটি ছোট, কিন্তু মূল সমস্যাটি ছিল ইনপুট মানের সমস্ত সংমিশ্রণের সাথে সামঞ্জস্য বজায় রেখে memcpy এবং memmove ফাংশনগুলির কার্য সম্পাদনের গতি বজায় রাখা এবং কর্মক্ষমতার অবনতি দূর করা।

জুনের শুরুতে, দুটি প্যাচ ভ্যারিয়েন্ট প্রস্তুত করা হয়েছিল, যা Glibc রক্ষণাবেক্ষণকারীদের টেস্ট ফ্রেমওয়ার্ক এবং Aurora-র অভ্যন্তরীণ টেস্ট স্যুট উভয়ই উত্তীর্ণ হয়। ৩রা জুন, ভ্যারিয়েন্টগুলোর মধ্যে একটিকে নির্বাচন করা হয় এবং পাঠানো হয়েছে Glibc মেইলিং লিস্টে। এক সপ্তাহের মধ্যে
মনে হচ্ছিল প্রস্তাবিত একই ধরনের পদ্ধতিতে তৈরি আরেকটি প্যাচ মাল্টিআর্ক বাস্তবায়নের একটি সমস্যা সমাধান করেছে, যা হুয়াওয়ে পূর্বে সমাধান করার চেষ্টা করেছিল। এটি পরীক্ষা করতে এক মাস সময় লেগেছিল এবং আইনি নিবন্ধন প্যাচটির গুরুত্বের কারণে।
৮ই জুলাইয়ের সংশোধন গৃহীত হয়েছিল আসন্ন glibc 2.32 রিলিজের প্রধান শাখায়। এই বাস্তবায়নে দুটি প্যাচ অন্তর্ভুক্ত রয়েছে: первый ARMv7-এর জন্য memcpy-এর মাল্টিআর্ক বাস্তবায়নের জন্য, এবং দ্বিতীয়টি ARM-এর জন্য memcpy() এবং memmove() ফাংশনের একটি সাধারণ অ্যাসেম্বলি বাস্তবায়নের জন্য।

এই সমস্যাটি লক্ষ লক্ষ ARMv7 ডিভাইসকে প্রভাবিত করে, যেগুলোর Linux যথাযথ আপডেট ছাড়া, মালিকদের সেগুলোকে নেটওয়ার্কের সাথে সংযুক্ত করার ঝুঁকি থাকে (নেটওয়ার্ক-অ্যাক্সেসযোগ্য পরিষেবা এবং অ্যাপ্লিকেশন, যেগুলো আকারের সীমাবদ্ধতা ছাড়াই ইনপুট ডেটা গ্রহণ করে, সেগুলো আক্রান্ত হতে পারে)। উদাহরণস্বরূপ, যে গবেষকরা এই দুর্বলতাটি আবিষ্কার করেছেন, তাদের তৈরি করা এক্সপ্লয়েটটি দেখায় যে কীভাবে একটি অত্যন্ত বড় GET রিকোয়েস্ট পাঠিয়ে গাড়ির ইনফরমেশন সিস্টেমে থাকা HTTP সার্ভারকে আক্রমণ করা যায় এবং সিস্টেমের রুট অ্যাক্সেস লাভ করা যায়।

উত্স: opennet.ru