تھیو ڈی راڈٹ W^X (Write XOR Execute) میموری پروٹیکشن میکانزم کو مضبوط بنانے کا منصوبہ ہے۔ میکانزم کا نچوڑ یہ ہے کہ پراسیس میموری پیجز تک بیک وقت تحریر اور عمل درآمد کے لیے رسائی نہیں کی جا سکتی۔ اس طرح، تحریر کو غیر فعال کرنے کے بعد ہی کوڈ پر عمل درآمد کیا جا سکتا ہے، اور میموری کے صفحے پر لکھنا صرف عمل درآمد کے غیر فعال ہونے کے بعد ہی ممکن ہے۔ W^X میکانزم یوزر اسپیس ایپلی کیشنز کو عام بفر اوور فلو حملوں سے بچانے میں مدد کرتا ہے، بشمول اسٹیک اوور فلو، اور OpenBSD میں فعال ہے۔ .
W^X پر کام کے آغاز سے، یہ واضح تھا کہ یہ ایک طویل راستہ تھا، کیونکہ JIT کا استعمال کرنے والی درخواستوں کی ایک خاصی تعداد تھی۔ جے آئی ٹی کے نفاذ کو تین اقسام میں تقسیم کیا جا سکتا ہے۔
- W اور X ریاستوں کے درمیان میموری کو تبدیل کرنا، سسٹم کال کی "قیمت" کو قبول کرنا .
- ایک ہی میموری کی W اور X میپنگ کے جوڑے کے درمیان عرفی نام بنانا۔
- سب سے زیادہ "گندے" آپشن کے لیے W|X میموری ماڈل کی ضرورت ہوتی ہے جو بیک وقت ریکارڈنگ اور عمل درآمد کی اجازت دیتا ہے۔
فی الحال، تیسرے آپشن کا استعمال کرتے ہوئے نمایاں طور پر کم پروگرام ہیں اور پہلے اور دوسرے کا استعمال کرتے ہوئے زیادہ۔ تاہم، چونکہ W|X JIT (بنیادی طور پر Chromium اور Iridum) کے ساتھ پروگراموں کو چلانا ضروری تھا، اس لیے ایک "wxallowed" فائل سسٹم ماؤنٹ آپشن شامل کیا گیا، جس سے میموری کو تحریری اور عملدرآمد دونوں کے لیے بیک وقت استعمال کرنے کی اجازت دی گئی، اس صورت میں اگر قابل عمل ELF فائل کو "wxneeded" مارکر کے ساتھ نشان زد کیا گیا ہے، اور ایپلی کیشنز کو خود بھی میکانزم کے ذریعے محفوظ کیا گیا تھا۔ и استعمال شدہ سسٹم کالز کی فہرست اور ایپلیکیشن کے لیے دستیاب فائل سسٹم کے حصوں کو بالترتیب محدود کرنے کے لیے۔
اس طرح کی ایپلی کیشنز میں کمزوریوں کے استحصال کو مزید پیچیدہ بنانے کے لیے میکانزم میں اضافے کی تجویز دی گئی ہے۔ ، جو چیک کرتا ہے کہ آیا سسٹم کال کو قابل تحریر میموری والے صفحہ سے انجام دیا جا رہا ہے۔ اگر صفحہ قابل تحریر ہے تو عمل کو ختم کرنے پر مجبور کیا جاتا ہے۔ اس طرح، حملہ آور سسٹم کالز کا فائدہ نہیں اٹھا سکے گا اور جے آئی ٹی کے نفاذ میں ضروری گیجٹس تلاش کرنے کی کوشش کرنے پر مجبور ہو جائے گا یا سسٹم کال اسٹبس کا براہ راست اندر سے پتہ لگانے کا زیادہ مشکل کام بھی کرے گا۔ .
کروم/ایریڈیم کے عمل پہلے سے ہی عہد اور نقاب کشائی کا استعمال کرتے ہوئے کافی قابل اعتماد طریقے سے محفوظ ہیں، لیکن استعمال کرنے کی صلاحیت کو ہٹانا، مثال کے طور پر، رائٹ(2) سسٹم کال کا واضح طور پر کچھ فائدہ ہے، کیونکہ یہ حملہ آور کے لیے اضافی مشکلات پیدا کرتا ہے۔ تاہم، مشکلات بھی پیدا ہو سکتی ہیں اگر JIT کا نفاذ W|X میموری سے مقامی سسٹم کالز کا استعمال کرتا ہے۔ تاہم، امید کرنے کی وجہ ہے کہ ایسا نہیں ہوگا، کیونکہ ABI کو کئی بار تبدیل کیا گیا ہے، لیکن کسی نے بھی مسائل کی اطلاع نہیں دی۔
تبدیلیاں OpenBSD-Current برانچ کے باقاعدہ سنیپ شاٹس میں پہلے سے ہی دستیاب ہیں، ہر دلچسپی رکھنے والے کو جانچ کے لیے مدعو کیا جاتا ہے۔
Chrome/Iridium میں موڈ کی ظاہری شکل کے بارے میں متعلقہ خبریں تھیو کی طرف سے ایک الگ تبصرے کی مستحق ہیں۔ . اس کے نقطہ نظر سے، یہ کچھ استعمال کے ماڈلز کے لیے قابل قبول ہے، لیکن شاید سب کے لیے نہیں، کیونکہ یہ موڈ ظاہر ہے کہ پروسیسر پر بوجھ بڑھائے گا۔ فی الحال، کروم زیادہ تر کام کرے گا اگر آپ /usr/local کے لیے "wxallowed" کو غیر فعال کر دیں گے، حالانکہ کچھ ایکسٹینشنز میں دشواری ہو سکتی ہے (گوسٹری ایک مثال ہے)۔ ایک یا دوسرے طریقے سے تھیو کو امید ہے کہ JITless موڈ میں مکمل کام کو مستقبل قریب میں مکمل طور پر آپریشنل حالت میں لایا جائے گا۔
ماخذ: opennet.ru