Glibc ۾ ارورا او ايس ڊولپرز پاران تيار ڪيل memcpy خطري لاءِ هڪ حل شامل آهي

ارورا موبائل آپريٽنگ سسٽم جي ڊولپرز (اوپن موبائل پليٽ فارم ڪمپني پاران تيار ڪيل سيل فش او ايس جو هڪ ڪانٽو) کي ختم ڪرڻ بابت هڪ پڌري ڪهاڻي شيئر ڪئي نازڪ ڪمزوري (CVE-2020-6096) Glibc ۾، جيڪو صرف ARMv7 پليٽ فارم تي ظاهر ٿئي ٿو. نقصان جي باري ۾ معلومات مئي ۾ واپس ظاهر ڪئي وئي، پر تازو ڏينهن تائين، فيڪس موجود نه هئا، حقيقت جي باوجود ته نقصانات مقرر ڪيل خطري جي هڪ اعلي سطح ۽ هڪ استحصال جو هڪ ڪم ڪندڙ پروٽوٽائپ آهي جيڪو توهان کي ڪوڊ جي عمل کي منظم ڪرڻ جي اجازت ڏئي ٿو جڏهن پروسيسنگ ڊيٽا کي هڪ خاص طريقي سان فارميٽ ڪيو memcpy() ۽ memmove() افعال ۾. پيڪيج جي اصلاح لاءِ ديبين и Ubuntu اڃا تائين جاري نه ڪيا ويا آهن ۽ ڪمزوري تقريبن ٻن مهينن تائين اڻڄاتل رهي ٿي عوامي ظاهر ٿيڻ جي لمحن کان ۽ پنجن مهينن کان ان وقت کان جڏهن Glibc ڊولپرز کي اطلاع ڏنو ويو.

ڪمزوري پاڻ کي ARMv7 لاءِ اسيمبلي جي ٻولي ۾ memcpy() ۽ memmove() جي عمل درآمد ۾ ظاهر ڪيو ۽ پيراميٽر جي منفي قدرن جي غلط پروسيسنگ جي ڪري ٿي جيڪا نقل ڪيل علائقي جي سائيز کي طئي ڪري ٿي. پيچ جي ترقي سان مسئلا شروع ٿي جڏهن ڪمپنيون SUSE и ڳاڙهو Hat Hat اعلان ڪيو ته انهن جي پليٽ فارمن جي مسئلي کان متاثر نه آهن، ڇاڪاڻ ته اهي 32-bit ARMv7 سسٽم لاء نه ٺاهيندا آهن، ۽ فيڪس ٺاهڻ ۾ حصو نه وٺندا آهن. ڪيترن ئي سرايت ٿيل تقسيم جي ڊولپرز Glibc ٽيم تي ڀروسو ڪيو آهي، ۽ پڻ فعال طور تي فيڪس تيار ڪرڻ ۾ شامل نه ڪيو ويو آهي.

آپشن پيچ مسئلي کي بلاڪ ڪرڻ لاءِ، Huawei لڳ ڀڳ فوري طور تي تجويز ڪيو ته اها اسمبلي جي هدايتن کي تبديل ڪرڻ جي ڪوشش ڪئي جيڪا سائن ان ٿيل آپرينڊز (bge ۽ blt) سان ڪم ڪندي غير دستخط ٿيل اينالاگز (blo ۽ bhs) سان. Glibc سنڀاليندڙن مختلف غلطين جي حالتن کي جانچڻ لاءِ ٽيسٽ جو هڪ سيٽ تيار ڪيو، جنهن کان پوءِ اهو معلوم ٿيو ته Huawei پيچ مناسب نه هو ۽ ان پٽ ڊيٽا جي سڀني ممڪن مجموعن تي عمل نه ڪيو.

جيئن ته Aurora OS وٽ ARM لاءِ 32-bit بلڊ آهي، ان جي ڊولپرز فيصلو ڪيو ته پاڻ ئي نقصان کي بند ڪري ۽ ڪميونٽي کي حل پيش ڪن. ڏکيائي اها هئي ته اهو ضروري هو ته هڪ موثر اسمبلي ٻولي لکڻ جي فنڪشن کي لاڳو ڪيو وڃي ۽ ان پٽ دليلن لاءِ مختلف اختيارن کي مدنظر رکيو وڃي. غير دستخط ٿيل هدايتون استعمال ڪندي عمل درآمد کي ٻيهر لکيو ويو آهي. پيچ اهو ننڍڙو ٿي ويو، پر بنيادي مسئلو عمل جي رفتار کي برقرار رکڻ ۽ memcpy ۽ memmove افعال جي ڪارڪردگي جي خرابي کان بچڻ، جڏهن ته ان پٽ جي قيمتن جي سڀني مجموعن سان مطابقت برقرار رکندي هئي.

جون جي شروعات ۾، فيڪس جا ٻه نسخا تيار ڪيا ويا، Glibc سنڀاليندڙن جي ٽيسٽ فريم ورڪ ۽ اورورا جي اندروني ٽيسٽ سوٽ کي پاس ڪرڻ. 3 جون تي، اختيارن مان ھڪڙو چونڊيو ويو ۽ موڪليو ويو Glibc ميلنگ لسٽ ڏانهن. هڪ هفتي بعد
هو تجويز ڪيل هڪ ٻيو پيچ ساڳيو طريقي سان، جنهن ۾ هڪ مسئلو حل ڪيو ملٽيارچ عمل درآمد ۾، جنهن کي Huawei اڳ ۾ ئي حل ڪرڻ جي ڪوشش ڪئي هئي. ٽيسٽ هڪ مهينو ورتو ۽ قانوني رجسٽريشن پيچ جي اهميت جي ڪري.
8 جولاء تي ترميمون قبول ڪيا ويا ايندڙ glibc 2.32 رليز جي مکيه شاخ ڏانهن. عملدرآمد ۾ ٻه پيچ شامل آهن - первый ARMv7 لاءِ memcpy جي ملٽي آرڪ عمل درآمد لاءِ، ۽ ٻيو ARM لاءِ memcpy() ۽ memmove() جي جنرل اسيمبلي جي ٻولي لاڳو ڪرڻ لاءِ.

مسئلو لکين ARMv7 ڊوائيسز کي متاثر ڪري ٿو جيڪي لينڪس هلائي رهيا آهن، ۽ مناسب اپڊيٽ جي بغير، مالڪن کي خطرو آهي جڏهن انهن کي نيٽ ورڪ سان ڳنڍيندا آهن (نيٽ ورڪ تائين رسائي واريون خدمتون ۽ ايپليڪيشنون جيڪي ان پٽ ڊيٽا کي قبول ڪن ٿيون بغير سائيز جي پابندين تي حملو ڪري سگهجي ٿو). مثال طور، تحقيق ڪندڙن پاران تيار ڪيل استحصال جيڪو خطرن جي نشاندهي ڪري ٿو اهو ڏيکاري ٿو ته ڪيئن هڪ تمام وڏي GET درخواست موڪلڻ ۽ سسٽم تائين روٽ رسائي حاصل ڪندي ڪار انفارميشن سسٽم ۾ ٺهيل هڪ HTTP سرور تي حملو ڪيو.

جو ذريعو: opennet.ru

تبصرو شامل ڪريو