Kees Cook، سابق kernel.org CSO اور Ubuntu سیکیورٹی ٹیم کے رہنما، جو اب Google کے لیے Android اور ChromeOS کو محفوظ بنانے کے لیے کام کرتے ہیں، نے کرنل کی مستحکم شاخوں میں کیڑے ٹھیک کرنے کے موجودہ عمل کے بارے میں تشویش کا اظہار کیا۔ ہر ہفتے، مستحکم شاخوں میں تقریباً سو فکسز شامل کیے جاتے ہیں، اور اگلی ریلیز میں تبدیلیاں قبول کرنے کے لیے ونڈو کو بند کرنے کے بعد، یہ ایک ہزار تک پہنچ جاتا ہے (مینٹینرز ونڈو کے بند ہونے تک فکسز رکھتے ہیں، اور "-rc1" کی تشکیل کے بعد وہ جمع شدہ کو ایک ساتھ شائع کریں) جو کہ بہت زیادہ ہے اور لینکس کرنل پر مبنی دیکھ بھال کی مصنوعات کے لیے بہت زیادہ محنت درکار ہے۔
کیز کے مطابق، کرنل میں غلطیوں کے ساتھ کام کرنے کے عمل پر مناسب توجہ نہیں دی جاتی ہے اور کرنل کے پاس اس علاقے میں مربوط کام کے لیے کم از کم 100 اضافی ڈویلپرز کی کمی ہے۔ کور کرنل ڈویلپرز مستقل بنیادوں پر کیڑے ٹھیک کرتے ہیں، لیکن اس بات کی کوئی گارنٹی نہیں ہے کہ ان اصلاحات کو تیسرے فریق کے ذریعے استعمال کیے جانے والے کرنل کی مختلف حالتوں میں پورٹ کیا جائے گا۔ لینکس کرنل پر مبنی مختلف پروڈکٹس کے صارفین کے پاس بھی یہ کنٹرول کرنے کا کوئی طریقہ نہیں ہے کہ کون سے کیڑے ٹھیک ہیں اور کون سا دانا ان کے آلات میں استعمال ہوتا ہے۔ فروخت کنندگان بالآخر اپنی مصنوعات کی حفاظت کے ذمہ دار ہیں، لیکن دانا کی مستحکم شاخوں میں بہت زیادہ پیچنگ کی شرح کے ساتھ، انہیں تمام پیچ کو بیک پورٹ کرنے، سب سے اہم کو منتخب طور پر پورٹ کرنے، یا تمام پیچ کو نظر انداز کرنے کے درمیان انتخاب کا سامنا کرنا پڑا۔
بہترین حل یہ ہوگا کہ صرف اہم ترین اصلاحات اور کمزوریوں کو منتقل کیا جائے، لیکن ایسی غلطیوں کو عام بہاؤ سے الگ کرنا بنیادی مسئلہ ہے۔ پاپ اپ ہونے والے زیادہ تر مسائل C زبان کے استعمال کی وجہ سے ہوتے ہیں، جس میں میموری اور پوائنٹرز سے نمٹنے کے دوران بہت احتیاط کی ضرورت ہوتی ہے۔ معاملات کو مزید خراب کرنے کے لیے، بہت سے ممکنہ خطرے سے متعلق اصلاحات CVE شناخت کنندگان کے ساتھ فراہم نہیں کی جاتی ہیں، یا پیچ شائع ہونے کے کچھ وقت بعد ایسا شناخت کنندہ وصول کرتے ہیں۔ ایسے حالات میں، مینوفیکچررز کے لیے معمولی اصلاحات کو بڑے سیکیورٹی مسائل سے الگ کرنا بہت مشکل ہے۔ اعداد و شمار کے مطابق، CVE کے تفویض ہونے سے پہلے 40% سے زیادہ کمزوریاں طے ہو جاتی ہیں، اور ایک فکس کے اجراء اور CVE کی تفویض کے درمیان اوسط تاخیر تین ماہ ہوتی ہے (یعنی، شروع میں، فکس کو سمجھا جاتا ہے ایک عام بگ، لیکن چند مہینوں کے بعد ہی یہ واضح ہو جاتا ہے کہ کمزوری ٹھیک ہو گئی ہے)۔
نتیجتاً، کمزوریوں کے لیے اصلاحات کے ساتھ علیحدہ برانچ کے بغیر اور کسی خاص مسئلے کے سیکیورٹی کنکشن کے بارے میں معلومات حاصل کیے بغیر، لینکس کرنل پر مبنی مصنوعات کے مینوفیکچررز کو تازہ مستحکم شاخوں سے تمام اصلاحات کو مسلسل منتقل کرنے کے لیے چھوڑ دیا جاتا ہے۔ لیکن اس کام کے لیے بہت زیادہ محنت درکار ہوتی ہے اور رجعت پسند تبدیلیوں کے خوف کی وجہ سے کمپنیوں میں مزاحمت کا سامنا کرنا پڑتا ہے جو پروڈکٹ کے معمول کے عمل میں خلل ڈال سکتی ہیں۔
یاد رکھیں کہ، Linus Torvalds کے مطابق، تمام غلطیاں اہم ہیں اور خطرات کو دوسری قسم کی غلطیوں سے الگ نہیں کیا جانا چاہیے اور ایک علیحدہ اعلی ترجیحی زمرے میں مختص کیا جانا چاہیے۔ اس رائے کی وضاحت اس حقیقت سے کی گئی ہے کہ ایک عام ڈویلپر کے لیے جو سیکورٹی کے مسائل میں مہارت نہیں رکھتا، ایک فکس اور ممکنہ کمزوری کے درمیان تعلق واضح نہیں ہے (کئی اصلاحات کے لیے، صرف ایک علیحدہ آڈٹ آپ کو یہ سمجھنے کی اجازت دیتا ہے کہ ان کا تعلق سیکیورٹی سے ہے۔ )۔ لینس کے مطابق، یہ ان ٹیموں کی سیکیورٹی ٹیموں پر منحصر ہے جو لینکس ڈسٹری بیوشنز پر کرنل پیکجز کو برقرار رکھنے کے لیے ذمہ دار ہیں تاکہ عام پیچ کے بہاؤ سے ممکنہ خطرات کو الگ کیا جا سکے۔
Kees Cook کا خیال ہے کہ مناسب طویل مدتی لاگت پر دانا کو محفوظ رکھنے کا واحد حل کمپنیوں کے لیے یہ ہے کہ وہ مقامی کرنل کی تعمیر میں پیچ پورٹ کرنے میں ملوث انجینئرز کو اپ اسٹریم کرنل میں پیچ اور کمزوریوں کو برقرار رکھنے کے لیے باہمی تعاون اور ہم آہنگی سے کام کرنے کے لیے منتقل کریں۔ اس کی موجودہ شکل میں، بہت سے مینوفیکچررز اپنی مصنوعات میں کرنل کا تازہ ترین ورژن استعمال نہیں کرتے اور خود ہی بیک پورٹ فکس کرتے ہیں، یعنی یہ پتہ چلتا ہے کہ مختلف کمپنیوں میں انجینئر ایک دوسرے کے کام کی نقل تیار کرتے ہیں، اسی مسئلے کو حل کرتے ہیں۔
مثال کے طور پر، اگر 10 کمپنیاں، جن میں سے ہر ایک انجینئر ایک ہی اصلاحات کی حمایت کر رہا ہے، ان انجینئرز کو بگس کو اپ اسٹریم میں ٹھیک کرنے کے لیے ری ڈائریکٹ کریں، بجائے اس کے کہ ایک ہی فکس کو پورٹ کریں، وہ عام فائدے کے لیے 10 مختلف کیڑے ٹھیک کر سکتے ہیں یا مجوزہ تبدیلیوں کے جائزے میں شامل ہو سکتے ہیں۔ بگی کوڈ کو دانا میں شامل ہونے سے روکیں۔ وسائل کو جانچ اور کوڈ کے تجزیے کے لیے نئے ٹولز بنانے کے لیے بھی وقف کیا جا سکتا ہے، جو کہ ابتدائی مرحلے میں خود بخود غلطیوں کی مخصوص کلاسوں کی شناخت کر سکیں گے جو بار بار پاپ اپ ہوتی ہیں۔
Kees Cook بنیادی ترقی کے عمل میں براہ راست خودکار اور مبہم ٹیسٹنگ کے زیادہ فعال استعمال، مسلسل انضمام کے نظام کے استعمال اور ای میل کے ذریعے قدیم ترقیاتی انتظام کو ترک کرنے کا مشورہ بھی دیتا ہے۔ فی الحال، مؤثر جانچ میں اس حقیقت کی وجہ سے رکاوٹ ہے کہ جانچ کے اہم عمل ترقی سے الگ ہوتے ہیں اور ریلیز کی تشکیل کے بعد ہوتے ہیں۔ کیز نے کیڑے کو کم کرنے کے لیے زیادہ محفوظ زبانیں، جیسے Rust، استعمال کرنے کی بھی سفارش کی۔
ماخذ: opennet.ru