ارورہ موبائل آپریٹنگ سسٹم کے ڈویلپرز (اوپن موبائل پلیٹ فارم کمپنی کے ذریعہ تیار کردہ سیل فش او ایس کا ایک کانٹا) نے اس کے خاتمے کے بارے میں ایک انکشافی کہانی شیئر کی۔ () Glibc میں، جو صرف ARMv7 پلیٹ فارم پر ظاہر ہوتا ہے۔ خطرے کے بارے میں معلومات کا انکشاف مئی میں کیا گیا تھا، لیکن حالیہ دنوں تک، اصلاحات دستیاب نہیں تھیں، اس حقیقت کے باوجود کہ خطرات خطرے کی ایک اعلی سطح اور ایک استحصال کا ایک ورکنگ پروٹو ٹائپ ہے جو آپ کو memcpy() اور memmove() فنکشنز میں کسی خاص طریقے سے فارمیٹ شدہ ڈیٹا پر کارروائی کرتے وقت کوڈ پر عمل درآمد کو منظم کرنے کی اجازت دیتا ہے۔ کے لیے پیکیج کی اصلاحات и ابھی تک جاری نہیں کیا گیا ہے اور عوامی افشاء کے لمحے سے تقریباً دو ماہ تک اور Glibc کے ڈویلپرز کو مطلع کیے جانے کے وقت سے پانچ ماہ تک خطرہ غیر متعین ہے۔
کمزوری خود کو ARMv7 کے لیے اسمبلی لینگویج میں memcpy() اور memmove() کے نفاذ میں ظاہر ہوئی اور اس کی وجہ پیرامیٹر کی منفی اقدار کی غلط پروسیسنگ ہے جو کاپی شدہ علاقے کے سائز کا تعین کرتی ہے۔ پیچ کی ترقی کے ساتھ مسائل شروع ہوئے جب کمپنیوں и نے اعلان کیا کہ ان کے پلیٹ فارمز اس مسئلے سے متاثر نہیں ہوتے ہیں، کیونکہ وہ 32-bit ARMv7 سسٹمز کے لیے نہیں بناتے ہیں، اور اس نے فکس بنانے میں حصہ نہیں لیا تھا۔ ایسا لگتا ہے کہ بہت سی ایمبیڈڈ ڈسٹری بیوشنز کے ڈویلپرز نے Glibc ٹیم پر بھروسہ کیا ہے، اور وہ فکس کی تیاری میں بھی فعال طور پر شامل نہیں ہوئے ہیں۔
آپشن۔ مسئلہ کو روکنے کے لیے، ہواوے نے تقریباً فوراً تجویز پیش کی کہ اس نے دستخط شدہ آپرینڈز (bge اور blt) کے ساتھ چلنے والی اسمبلی ہدایات کو غیر دستخط شدہ اینالاگ (blo اور bhs) سے تبدیل کرنے کی کوشش کی۔ Glibc مینٹینرز نے خرابی کی مختلف حالتوں کو چیک کرنے کے لیے ٹیسٹوں کا ایک سیٹ تیار کیا، جس کے بعد پتہ چلا کہ Huawei پیچ مناسب نہیں تھا اور اس نے ان پٹ ڈیٹا کے تمام ممکنہ امتزاج پر کارروائی نہیں کی۔
چونکہ Aurora OS کے پاس ARM کے لیے 32 بٹ کی تعمیر ہے، اس لیے اس کے ڈویلپرز نے اپنے طور پر خطرے کو ختم کرنے اور کمیونٹی کو حل پیش کرنے کا فیصلہ کیا۔ مشکل یہ تھی کہ فنکشن کے موثر اسمبلی لینگویج پر عمل درآمد لکھنا اور ان پٹ آرگیومنٹس کے لیے مختلف آپشنز کو مدنظر رکھنا ضروری تھا۔ نفاذ کو غیر دستخط شدہ ہدایات کا استعمال کرتے ہوئے دوبارہ لکھا گیا ہے۔ یہ چھوٹا نکلا، لیکن بنیادی مسئلہ عمل کی رفتار کو برقرار رکھنا اور memcpy اور memmove فنکشنز کی کارکردگی میں کمی سے بچنا تھا، جبکہ ان پٹ ویلیوز کے تمام امتزاج کے ساتھ مطابقت برقرار رکھنا تھا۔
جون کے آغاز میں، فکس کے دو ورژن تیار کیے گئے، جو Glibc مینٹینرز کے ٹیسٹ فریم ورک اور ارورہ کے اندرونی ٹیسٹ سوٹ کو پاس کرتے ہوئے۔ 3 جون کو، آپشنز میں سے ایک کا انتخاب کیا گیا اور Glibc میلنگ لسٹ میں۔ ایک ہفتے بعد
تھا اسی طرح کا ایک اور پیچ، جس نے ملٹی آرک نفاذ میں ایک مسئلہ کو درست کیا، جسے ہواوے نے پہلے حل کرنے کی کوشش کی تھی۔ جانچ میں ایک مہینہ لگا اور پیچ کی اہمیت کی وجہ سے۔
8 جولائی کی اصلاحات آنے والی glibc 2.32 ریلیز کی مرکزی شاخ میں۔ نفاذ میں دو پیچ شامل ہیں۔ ARMv7 کے لیے memcpy کے ملٹی آرک نفاذ کے لیے، اور ARM کے لیے memcpy() اور memmove() کے جنرل اسمبلی لینگویج کے نفاذ کے لیے۔
یہ مسئلہ لینکس چلانے والے لاکھوں ARMv7 ڈیوائسز کو متاثر کرتا ہے، اور مناسب اپ ڈیٹ کے بغیر، مالکان کو نیٹ ورک سے منسلک کرتے وقت خطرہ لاحق ہوتا ہے (نیٹ ورک سے قابل رسائی خدمات اور ایپلیکیشنز جو سائز کی پابندیوں کے بغیر ان پٹ ڈیٹا کو قبول کرتے ہیں ان پر حملہ کیا جا سکتا ہے)۔ مثال کے طور پر، خطرے کی نشاندہی کرنے والے محققین کے ذریعہ تیار کردہ استحصال سے پتہ چلتا ہے کہ کس طرح ایک بہت بڑی GET درخواست بھیج کر کار انفارمیشن سسٹم میں بنائے گئے HTTP سرور پر حملہ کیا جائے اور سسٹم تک جڑ تک رسائی حاصل کی جائے۔
ماخذ: opennet.ru