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

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

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

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

যেহেতু Aurora OS-এর ARM-এর জন্য একটি 32-বিট বিল্ড রয়েছে, তাই এর বিকাশকারীরা নিজেরাই দুর্বলতা বন্ধ করার এবং সম্প্রদায়কে একটি সমাধান দেওয়ার সিদ্ধান্ত নিয়েছে। অসুবিধা ছিল যে ফাংশনের একটি দক্ষ সমাবেশ ভাষা বাস্তবায়ন লিখতে এবং ইনপুট আর্গুমেন্টের জন্য বিভিন্ন বিকল্প বিবেচনা করা প্রয়োজন ছিল। স্বাক্ষরবিহীন নির্দেশাবলী ব্যবহার করে বাস্তবায়ন পুনরায় লেখা হয়েছে। তালি এটি ছোট হতে দেখা গেল, তবে প্রধান সমস্যাটি ছিল কার্যকর করার গতি বজায় রাখা এবং মেমসিপি এবং মেমমোভ ফাংশনগুলির কার্যক্ষমতা হ্রাস এড়ানো, ইনপুট মানগুলির সমস্ত সংমিশ্রণের সাথে সামঞ্জস্য বজায় রাখা।

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

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

উত্স: opennet.ru