GRUB2 بوٹ لوڈر میں NTFS فائل سسٹم کو سپورٹ کرنے والے ڈرائیور میں ایک کمزوری (CVE-2023-4692) کی نشاندہی کی گئی ہے۔ یہ کمزوری بوٹ لوڈر کی سطح پر اپنی مرضی کے کوڈ کے نفاذ کی اجازت دیتی ہے جب خاص طور پر تیار کردہ فائل سسٹم کی تصویر تک رسائی حاصل کی جاتی ہے۔ UEFI سیکیور بوٹ تصدیق شدہ بوٹ میکانزم کو نظرانداز کرنے کے لیے اس کمزوری کا فائدہ اٹھایا جا سکتا ہے۔
یہ خطرہ NTFS انتساب "$ATTRIBUTE_LIST" (grub-core/fs/ntfs.c) کے پارسنگ کوڈ میں خرابی کی وجہ سے ہے، جس کا فائدہ صارف کے زیر کنٹرول معلومات کو مختص کردہ بفر سے باہر میموری کے مقام پر لکھنے کے لیے استعمال کیا جا سکتا ہے۔ خاص طور پر تیار کردہ NTFS امیج پر کارروائی کرتے وقت، اوور فلو GRUB میموری کے کچھ حصے کو اوور رائٹ کرنے کا باعث بنتا ہے اور، بعض شرائط کے تحت، UEFI فرم ویئر میموری کو خراب کرتا ہے، ممکنہ طور پر بوٹ لوڈر یا فرم ویئر کی سطح پر کوڈ کے نفاذ کی اجازت دیتا ہے۔
مزید برآں، GRUB2 میں NTFS ڈرائیور میں ایک اور کمزوری (CVE-2023-4693) دریافت ہوئی۔ یہ کمزوری خاص طور پر تیار کردہ NTFS امیج میں "$DATA" وصف کو پارس کرتے وقت صوابدیدی میموری کے مواد کو پڑھنے کی اجازت دیتی ہے۔ دیگر چیزوں کے علاوہ، یہ کمزوری میموری میں محفوظ کردہ حساس ڈیٹا کو نکالنے یا EFI متغیر اقدار کے تعین کی اجازت دیتی ہے۔
ابھی تک معاملات کو صرف پیچھا کیا گیا ہے۔ ڈسٹری بیوشنز میں خطرے سے متعلق اصلاحات کی حیثیت کا اندازہ ان صفحات پر لگایا جا سکتا ہے: Debian, Ubuntu، SUSE، RHEL، Fedora. GRUB2 کے مسائل کو ٹھیک کرنے کے لیے صرف پیکیج کو اپ ڈیٹ کرنے سے زیادہ کی ضرورت ہے۔ اس کے لیے نئے اندرونی ڈیجیٹل دستخط پیدا کرنے اور انسٹالرز، بوٹ لوڈرز، کرنل پیکجز، fwupd فرم ویئر، اور شیم لیئر کو اپ ڈیٹ کرنے کی بھی ضرورت ہے۔
سب سے زیادہ LinuxUEFI سیکیور بوٹ موڈ میں تصدیق شدہ بوٹ کے لیے ڈسٹری بیوشن میں ایک چھوٹی شیم لیئر کا استعمال کیا جاتا ہے، جس پر مائیکروسافٹ کے ذریعے ڈیجیٹل طور پر دستخط کیے گئے ہیں۔ یہ پرت اپنے سرٹیفکیٹ کے ساتھ GRUB2 کی تصدیق کرتی ہے، تقسیم کے ڈویلپرز کو مائیکروسافٹ کو ہر دانا اور GRUB اپ ڈیٹ کے بارے میں مطلع کرنے کی ضرورت کو ختم کرتی ہے۔ GRUB2 میں کمزوریاں کامیاب شیم تصدیق کے بعد، لیکن آپریٹنگ سسٹم کے بوٹ ہونے سے پہلے من مانی کوڈ پر عمل درآمد کی اجازت دیتی ہیں۔ یہ حملہ آوروں کو سیکیور بوٹ کے فعال ہونے پر اعتماد کی زنجیر کو توڑنے اور بوٹ کے بعد کے عمل پر مکمل کنٹرول حاصل کرنے کی اجازت دیتا ہے، مثال کے طور پر، دوسرے OS کو بوٹ کرنا، آپریٹنگ سسٹم کے اجزاء میں ترمیم کرنا، یا لاک ڈاؤن تحفظ کو نظرانداز کرنا۔
ڈیجیٹل دستخط کو منسوخ کیے بغیر کمزوری کو روکنے کے لیے، ڈسٹری بیوشنز SBAT (UEFI Secure Boot Advanced Targeting) میکانزم کا استعمال کر سکتی ہیں، جس کے لیے سب سے زیادہ مقبول ڈسٹری بیوشنز میں GRUB2، shim اور fwupd کے لیے سپورٹ لاگو کیا جاتا ہے۔ LinuxSBAT کو مائیکروسافٹ کے تعاون سے تیار کیا گیا تھا اور اس میں UEFI جزو کے قابل عمل فائلوں میں اضافی میٹا ڈیٹا شامل کرنا شامل ہے، بشمول مینوفیکچرر، پروڈکٹ، اجزاء اور ورژن کے بارے میں معلومات۔ یہ میٹا ڈیٹا ڈیجیٹل طور پر دستخط شدہ ہے اور UEFI سیکیور بوٹ کے لیے اجازت یافتہ یا مسترد شدہ اجزاء کی فہرستوں میں الگ سے شامل کیا جا سکتا ہے۔
SBAT سیکیور بوٹ کیز کو منسوخ کرنے کی ضرورت کے بغیر انفرادی اجزاء کے ورژن نمبروں کے لیے ڈیجیٹل دستخطوں کے استعمال کو روکنے کی اجازت دیتا ہے۔ SBAT کے ذریعے کمزوریوں کو مسدود کرنے کے لیے UEFI سرٹیفکیٹ ریووکیشن لسٹ (dbx) کے استعمال کی ضرورت نہیں ہے، لیکن دستخط پیدا کرنے اور GRUB2، شیم، اور تقسیم کے ذریعے فراہم کردہ دیگر بوٹ آرٹفیکٹس کو اپ ڈیٹ کرنے کے لیے اندرونی کلید کو تبدیل کرنے کی سطح پر انجام دیا جاتا ہے۔ SBAT کے متعارف ہونے سے پہلے، UEFI Revocation List (dbx) کو اپ ڈیٹ کرنا خطرے کو مکمل طور پر مسدود کرنے کے لیے ایک لازمی شرط تھی، کیونکہ حملہ آور، استعمال شدہ آپریٹنگ سسٹم سے قطع نظر، UEFI سیکیور بوٹ سے سمجھوتہ کرنے کے لیے بوٹ کی کو استعمال کر سکتا ہے۔
ماخذ: opennet.ru
