TL، ڊاڪٽر. هن آرٽيڪل ۾، اسان ڳوليون ٿا سخت اسڪيمون جيڪي ڪم ڪن ٿا دٻي کان ٻاهر پنجن مشهور لينڪس ڊويزنن تي. هر هڪ لاءِ، اسان ورتو ڊفالٽ ڪنييل ترتيب، سڀني پيڪيجز کي لوڊ ڪيو، ۽ منسلڪ بائنريز ۾ سيڪيورٽي اسڪيمن جو تجزيو ڪيو. غور ڪيل تقسيم آهن OpenSUSE 12.4، Debian 9، CentOS، RHEL 6.10 ۽ 7، انهي سان گڏ Ubuntu 14.04، 12.04 ۽ 18.04 LTS.

نتيجا ان ڳالهه جي تصديق ڪن ٿا ته بنيادي اسڪيمون جهڙوڪ اسٽيڪنگ ڪينري ۽ پوزيشن-آزاد ڪوڊ اڃا تائين سڀني طرفان اختيار نه ڪيا ويا آهن. ترتيب ڏيڻ وارن لاءِ صورتحال اڃا به خراب آهي جڏهن اها اسٽيڪ ڪليش وانگر خطرن جي خلاف تحفظ جي ڳالهه اچي ٿي ، جيڪا اشاعت کانپوءِ جنوري ۾ اسپاٽ لائٽ ۾ آئي. سسٽم جي خرابين بابت ڄاڻ. پر سڀ ڪجهه ايترو نا اميد ناهي. بائنري جو هڪ اهم تعداد بنيادي تحفظ جي طريقن کي لاڳو ڪري ٿو، ۽ انهن جو تعداد نسخ کان نسخ تائين وڌندو آهي.

جائزو ڏيکاريو ويو آهي ته حفاظتي طريقن جو سڀ کان وڏو تعداد Ubuntu 18.04 ۾ OS ۽ ايپليڪيشن جي سطحن تي لاڳو ڪيو ويو آهي، جنهن جي پٺيان Debian 9. ٻئي طرف، OpenSUSE 12.4، CentOS 7 ۽ RHEL 7 پڻ بنيادي تحفظ جي اسڪيمن کي لاڳو ڪن ٿا، ۽ اسٽيڪ ٽڪرين جي حفاظت. ڊفالٽ پيڪيجز جي تمام گھڻائي واري سيٽ سان اڃا به وڌيڪ وسيع طور تي استعمال ڪيو ويندو آهي.

تعارف

اعلي معيار جي سافٽ ويئر کي يقيني بڻائڻ ڏکيو آهي. جامد ڪوڊ جي تجزيي ۽ متحرڪ رن ٽائم تجزيي لاءِ جديد اوزارن جي وڏي تعداد جي باوجود، گڏوگڏ گڏ ڪرڻ وارن ۽ پروگرامنگ ٻولين جي ترقي ۾ اهم پيش رفت جي باوجود، جديد سافٽ ويئر اڃا تائين انهن خطرن جو شڪار آهي، جن جو مسلسل حملو ڪندڙن طرفان استحصال ڪيو وڃي ٿو. ماحوليات ۾ صورتحال اڃا به خراب آهي جنهن ۾ ورثي ڪوڊ شامل آهن. اهڙين حالتن ۾، اسان کي نه رڳو ممڪن استحصالي غلطيون ڳولڻ جي دائمي مسئلي سان منهن ڏيڻو پوي ٿو، پر اسان سخت پسمانده مطابقت واري فريم ورڪ کان پڻ محدود آهيون، جيڪي گهڻو ڪري اسان کي محدود، يا ان کان به بدتر، ڪمزور يا بگي ڪوڊ کي بچائڻ جي ضرورت آهي.

اهو آهي جتي پروگرامن جي حفاظت يا سختي جا طريقا راند ۾ اچن ٿا. اسان ڪجھ قسمن جي غلطين کي روڪي نٿا سگھون، پر اسان حملي ڪندڙ جي زندگي کي وڌيڪ ڏکيو بڻائي سگھون ٿا ۽ جزوي طور تي مسئلو حل ڪري سگھون ٿا روڪڻ يا روڪڻ سان. استحصال اهي غلطيون. اهڙي حفاظت سڀني جديد آپريٽنگ سسٽم ۾ استعمال ڪيو ويندو آهي، پر طريقن جي پيچيدگي، ڪارڪردگي ۽ ڪارڪردگي ۾ تمام گهڻو فرق آهي: اسٽيڪ ڪنريز ۽ ASLR مڪمل تحفظ لاء سي ايف آئي и آر پي. هن آرٽيڪل ۾، اسان ڏسنداسين ته ڊفالٽ ڪنفگريشن ۾ سڀ کان وڌيڪ مشهور لينڪس ڊسٽريبيوشن ۾ ڪهڙا تحفظ جا طريقا استعمال ڪيا ويندا آهن، ۽ بائنري جي ملڪيتن کي پڻ جانچيندا آهن جيڪي هر تقسيم جي پيڪيج مينيجمينٽ سسٽم ذريعي ورهايل آهن.

CVE ۽ سيڪيورٽي

اسان سڀني عنوانن سان مضمون ڏٺا آهن جهڙوڪ "سال جي سڀ کان وڌيڪ ڪمزور ايپليڪيشنون" يا "سڀ کان وڌيڪ ڪمزور آپريٽنگ سسٽم." عام طور تي اهي انگ اکر مهيا ڪن ٿا رڪارڊ جي ڪل تعداد تي خطرات جي باري ۾ CVE (عام ڪمزوري ۽ نمائش)، مان حاصل ڪيل قومي نقصان واري ڊيٽابيس (NVD) от اينسٽ ۽ ٻيا ذريعا. تنهن کان پوء، اهي ايپليڪيشنون يا او ايس سي وي ايز جي تعداد جي لحاظ کان درجه بندي آهن. بدقسمتي سان، جڏهن ته CVEs تمام ڪارائتو آهن مسئلن کي ٽريڪ ڪرڻ ۽ وينڊرز ۽ صارفين کي آگاهي ڏيڻ لاء، اهي سافٽ ويئر جي حقيقي سيڪيورٽي بابت ٿورو چوندا آهن.

مثال طور، غور ڪريو CVEs جو ڪل تعداد گذريل چئن سالن ۾ لينڪس ڪنيل لاءِ ۽ پنج سڀ کان وڌيڪ مقبول سرور جي تقسيم، يعني Ubuntu، Debian، Red Hat Enterprise Linux ۽ OpenSUSE.

جوڙ. 1

هي گراف اسان کي ڇا ٻڌائي ٿو؟ ڇا CVEs جي وڏي تعداد جو مطلب اهو آهي ته هڪ تقسيم ٻئي کان وڌيڪ خطرناڪ آهي؟ ڪو جواب نه. مثال طور، هن آرٽيڪل ۾ توهان ڏسندا ته ديبين وٽ مضبوط سيڪيورٽي ميڪانيزم آهي مقابلي ۾، چئو، OpenSUSE يا RedHat Linux، ۽ اڃا تائين Debian وڌيڪ CVEs آهن. تنهن هوندي، انهن جو مطلب لازمي طور تي ڪمزور سيڪيورٽي جو مطلب ناهي: جيتوڻيڪ هڪ CVE جي موجودگي اهو ظاهر نٿو ڪري ته ڇا هڪ خطرو آهي استحصال ڪيو ويو. شدت جا اسڪور هڪ اشارو مهيا ڪن ٿا ته ڪيئن شايد هڪ ڪمزوري جو استحصال، پر آخرڪار استحصال جو دارومدار گهڻو ڪري متاثر ٿيل نظام ۾ موجود تحفظات ۽ حملي آورن جي وسيلن ۽ صلاحيتن تي آهي. ان کان علاوه، CVE رپورٽن جي غير موجودگي ٻين بابت ڪجھ به نه چوي اڻ رجسٽرڊ يا نامعلوم ڪمزوريون. CVE ۾ فرق سافٽ ويئر جي معيار کان سواءِ ٻين سببن جي ڪري ٿي سگھي ٿو، بشمول ٽيسٽ لاءِ مختص ڪيل وسيلا يا صارف جي بنياد جي سائيز. اسان جي مثال ۾، ڊيبين جي اعلي تعداد ۾ CVEs شايد اهو ظاهر ڪري سگھن ٿا ته ڊيبين وڌيڪ سافٽ ويئر پيڪيجز موڪلي ٿو.

يقينن، CVE سسٽم مفيد معلومات مهيا ڪري ٿي جيڪا توهان کي مناسب تحفظ پيدا ڪرڻ جي اجازت ڏئي ٿي. اسان پروگرام جي ناڪاميءَ جي سببن کي جيتري بهتر سمجھنداسون، اوترو ئي آسان ٿيندو ته استحصال جي ممڪن طريقن کي سڃاڻڻ ۽ مناسب ميکانيزم تيار ڪرڻ. تشخيص ۽ جواب. تصوير ۾. 2 ڏيکاري ٿو ڪمزورين جا زمرا گذريل چئن سالن دوران سڀني تقسيم لاءِ (ذريعو). اهو فوري طور تي واضح آهي ته اڪثر CVEs هيٺ ڏنل ڀاڱن ۾ اچي وڃن ٿا: سروس جو انڪار (DoS)، ڪوڊ جي عملداري، اوور فلو، ميموري ڪرپشن، معلومات جي رسي (Exfiltration) ۽ استحقاق جي واڌ. جيتوڻيڪ ڪيترن ئي CVEs کي مختلف قسمن ۾ ڪيترائي ڀيرا ڳڻيا ويا آهن، عام طور تي ساڳيو مسئلا سال کان پوء جاري رهي ٿو. مضمون جي ايندڙ حصي ۾، اسان انهن خطرن جي استحصال کي روڪڻ لاءِ مختلف حفاظتي اسڪيمن جي استعمال جو جائزو وٺنداسين.

جوڙ. 2

ڪمن

هن آرٽيڪل ۾ اسان هيٺ ڏنل سوالن جا جواب ڏيڻ چاهيندا آهيون:

• لينڪس جي مختلف تقسيم جي سيڪيورٽي ڇا آهي؟ ڪنيل ۽ يوزر اسپيس ايپليڪيشنن ۾ ڪهڙيون حفاظتي ميکانيزم موجود آهن؟
• سيڪيورٽي ميڪانيزم کي اپنائڻ وقت جي حوالي سان تقسيم ۾ ڪيئن تبديلي آئي آهي؟
• هر تقسيم لاءِ پيڪيجز ۽ لائبريرين جو سراسري انحصار ڇا آهي؟
• هر بائنري لاءِ ڪهڙا تحفظات لاڳو ڪيا ويا آهن؟

تقسيم جي چونڊ

اهو ظاهر ٿئي ٿو ته ورهائڻ واري تنصيب تي صحيح انگ اکر ڳولڻ ڏکيو آهي، ڇاڪاڻ ته اڪثر ڪيسن ۾ ڊائون لوڊ جو تعداد اصل تنصيب جي تعداد کي ظاهر نٿو ڪري. جڏهن ته، يونڪس مختلف قسمن جي اڪثريت سرور سسٽم ٺاهيندي آهي (ويب سرورز تي 69,2٪، طرفان انگ اکر W3techs ۽ ٻيا ذريعا) ۽ انهن جو حصو مسلسل وڌي رهيو آهي. ان ڪري، اسان جي تحقيق لاءِ اسان پليٽ فارم تي دٻي کان ٻاهر موجود تقسيم تي ڌيان ڏنو Google Cloud. خاص طور تي، اسان هيٺ ڏنل OS چونڊيو:

ورڇ / ورزن
نيوڪلي
اڏاوت

OpenSUSE 12.4
4.12.14-95.3-ڊفالٽ
#1 SMP اربع 5 ڊسمبر 06:00:48 UTC 2018 (63a8d29)

ديبين 9
4.9.0-8-amd64
#1 SMP ديبين 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP اڱارو جنوري 15 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP جمعو 1 فيبروري 14:54:57 UTC 2019

Red Hat Enterprise Linux سرور 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP اربع نومبر 21 15:08:21 EST 2018

Red Hat Enterprise Linux سرور 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP خميس نومبر 15 17:36:42 UTC 2018

Ubuntu 14.04 (معتبر طاهر)
4.4.0-140-عام

#166~14.04.1-Ubuntu SMP ڇنڇر نومبر 17 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0-1026-جي سي پي
#27~16.04.1-Ubuntu SMP جمعو 7 ڊسمبر 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0-1026-جي سي پي
#27-Ubuntu SMP خميس 6 ڊسمبر 18:27:01 UTC 2018

ٽيبل 1

تجزيو

اچو ته ڊفالٽ ڪنيل جي ترتيب جو مطالعو ڪريون، انهي سان گڏ پيڪيجز جي ملڪيتن کي دستياب مينيجر ذريعي هر تقسيم جي دٻي مان ٻاهر. اهڙيء طرح، اسان صرف هر تقسيم جي ڊفالٽ آئيني مان پيڪيجز تي غور ڪندا آهيون، غير مستحڪم ذخيرو (جهڙوڪ ڊيبين 'ٽيسٽنگ' آئيني) ۽ ٽئين پارٽي پيڪيجز (جهڙوڪ معياري آئيني مان Nvidia پيڪيجز) کان پيڪيجز کي نظرانداز ڪندي. اضافي طور تي، اسان ڪسٽم ڪنييل تالیفات يا سيڪيورٽي سخت ترتيبن تي غور نه ڪندا آهيون.

ڪنييل ترتيبن جو تجزيو

اسان تي ٻڌل هڪ تجزياتي اسڪرپٽ لاڳو ڪيو مفت kconfig چيڪ ڪندڙ. اچو ته نامزد ٿيل تقسيم جي دٻي کان ٻاهر جي حفاظت جي معيارن کي ڏسو ۽ انهن جي فهرست سان ان جي مقابلي ۾ بنيادي خود دفاعي پروجيڪٽ (KSPP). هر ترتيب جي آپشن لاءِ، جدول 2 مطلوبہ سيٽنگ کي بيان ڪري ٿو: چيڪ باڪس انهن تقسيمن لاءِ آهي جيڪي KSSP سفارشن تي عمل ڪن ٿيون (شرطن جي وضاحت لاءِ هيٺيون ڏسو). هتي؛ مستقبل جي آرٽيڪلز ۾ اسين وضاحت ڪنداسين ته انهن مان ڪيترا حفاظتي طريقا وجود ۾ آيا ۽ انهن جي غير موجودگي ۾ سسٽم کي ڪيئن هيڪ ڪيو ويو).

عام طور تي، نئين ڪنلن ۾ دٻي کان ٻاهر سخت سيٽنگون آهن. مثال طور، CentOS 6.10 ۽ RHEL 6.10 تي 2.6.32 ڪرنل ۾ تمام گهڻيون نازڪ خاصيتون شامل آهن جيڪي نئين ڪنلن ۾ لاڳو ٿيل آهن جهڙوڪ ايس ايم پي, سخت RWX اجازتون، ايڊريس randomization يا copy2usr تحفظ. اهو نوٽ ڪيو وڃي ٿو ته ٽيبل ۾ ترتيب ڏيڻ جا ڪيترائي اختيار ڪرنل جي پراڻن نسخن ۾ موجود نه آهن ۽ حقيقت ۾ لاڳو نه آهن - اهو اڃا تائين مناسب تحفظ جي کوٽ جي طور تي ٽيبل ۾ ظاهر ڪيو ويو آهي. ساڳئي طرح، جيڪڏهن ڪو ترتيب ڏيڻ جو اختيار ڏنل نسخي ۾ موجود نه آهي، ۽ سيڪيورٽي جي ضرورت آهي ته اختيار کي غير فعال ڪيو وڃي، اهو سمجهي وڃي ٿو مناسب ترتيب.

هڪ ٻيو نقطو غور ڪرڻ لاءِ جڏهن نتيجن جي تشريح ڪئي وڃي: ڪجهه ڪنيل ترتيبون جيڪي حملي جي مٿاڇري کي وڌائين ٿيون انهن کي سيڪيورٽي لاءِ پڻ استعمال ڪري سگهجي ٿو. اهڙن مثالن ۾ شامل آهن uprobes ۽ kprobes، ڪنيل ماڊلز، ۽ BPF/eBPF. اسان جي سفارش آهي ته مٿين ميکانيزم کي استعمال ڪيو وڃي حقيقي تحفظ مهيا ڪرڻ لاءِ، ڇاڪاڻ ته اهي استعمال ڪرڻ لاءِ غير معمولي آهن ۽ انهن جو استحصال اهو سمجهندو آهي ته بدڪاري ڪندڙ عملدار اڳ ۾ ئي سسٽم ۾ پنهنجو پير قائم ڪري چڪا آهن. پر جيڪڏهن اهي اختيار فعال آهن، سسٽم منتظم کي فعال طور تي غلط استعمال جي نگراني ڪرڻ گهرجي.

جدول 2 ۾ داخلائن کي وڌيڪ ڏسندي، اسان ڏسون ٿا ته جديد ڪارنلز نقصانن جي استحصال کان بچاءُ لاءِ ڪيترائي آپشن مهيا ڪن ٿا جهڙوڪ معلومات جي رسي ۽ اسٽيڪ/هيپ اوور فلوز. بهرحال، اسان نوٽيس ڪيو آهي ته اڃا تائين سڀ کان وڌيڪ مشهور تقسيم اڃا تائين وڌيڪ پيچيده تحفظ لاڳو نه ڪيا آهن (مثال طور، پيچ سان سيڪيورٽي) يا ڪوڊ جي ٻيهر استعمال جي حملن جي خلاف جديد تحفظ (مثال طور. اسڪيمن سان ترتيب ڏيڻ جو ميلاپ جهڙوڪ R^X لاءِ ڪوڊ). معاملن کي وڌيڪ خراب ڪرڻ لاء، اڃا به وڌيڪ ترقي يافته دفاع حملن جي مڪمل حد جي خلاف حفاظت نه ڪندا آهن. تنهن ڪري، اهو ضروري آهي ته سسٽم جي منتظمين لاء سمارٽ ترتيبن کي مڪمل ڪرڻ لاء حل سان جيڪي پيش ڪن ٿا رن ٽائم استحصال ڳولڻ ۽ روڪٿام.

ايپليڪيشن تجزيو

تعجب جي ڳالهه ناهي، مختلف تقسيم ۾ مختلف پيڪيج جون خاصيتون، تاليف جا اختيار، لائبريري انحصار، وغيره آهن. لاڳاپيل تقسيم ۽ پيڪيجز جو هڪ ننڍڙو تعداد انحصار سان (مثال طور، Ubuntu يا Debian تي coreutils). اختلافن جو جائزو وٺڻ لاءِ، اسان سڀني دستياب پيڪيجز کي ڊائون لوڊ ڪيو، انھن جي مواد کي ڪڍيو، ۽ بائنري ۽ انحصار جو تجزيو ڪيو. هر پيڪيج لاءِ، اسان ٻين پيڪيجز جو ٽريڪ رکيو ان تي منحصر آهي، ۽ هر بائنري لاءِ، اسان ان جي انحصار کي ٽريڪ ڪيو. هن حصي ۾ اسان مختصر طور تي نتيجن کي بيان ڪريون ٿا.

تقسيم

مجموعي طور تي، اسان سڀني تقسيم لاء 361 پيڪيجز ڊائون لوڊ ڪيو، صرف ڊفالٽ آئيني مان پيڪيجز کي ڪڍڻ. اسان ELF ايگزيڪيوٽيبل کانسواءِ پيڪيجز کي نظر انداز ڪيو، جهڙوڪ ذريعن، فونٽس وغيره. فلٽر ڪرڻ کان پوءِ، 556 پيڪيجز باقي رهيا، جن ۾ ڪل 129 بائنريون شامل آهن. تقسيم جي وچ ۾ پيڪيجز ۽ فائلن جي تقسيم تصوير ۾ ڏيکاريل آهي. 569.

جوڙ. 3

توھان محسوس ڪري سگھو ٿا ته وڌيڪ جديد تقسيم، وڌيڪ پيڪيجز ۽ بائنري ان تي مشتمل آھي، جيڪو منطقي آھي. بهرحال، Ubuntu ۽ Debian پيڪيجز ۾ CentOS، SUSE ۽ RHEL جي ڀيٽ ۾ ڪيتريون ئي وڌيڪ بائنري (ٻنهي عمل ڪندڙ ۽ متحرڪ ماڊلز ۽ لائبريريون) شامل آهن، جيڪي ممڪن طور تي Ubuntu ۽ Debian جي حملي واري سطح تي اثر انداز ڪن ٿا (اهو ياد رکڻ گهرجي ته انگ سڀني نسخن جي سڀني بائنري کي ظاهر ڪن ٿا. پيڪيج، اهو آهي، ڪجهه فائلن کي ڪيترائي ڀيرا تجزيو ڪيو ويو آهي). اهو خاص طور تي اهم آهي جڏهن توهان پيڪيجز جي وچ ۾ انحصار تي غور ڪريو. اهڙيء طرح، هڪ واحد پيڪيج بائنري ۾ هڪ ڪمزور ماحولي نظام جي ڪيترن ئي حصن کي متاثر ڪري سگهي ٿو، جيئن هڪ ڪمزور لائبريري سڀني بائنري کي متاثر ڪري سگهي ٿو جيڪي ان کي درآمد ڪن ٿا. شروعاتي نقطي جي طور تي، اچو ته مختلف آپريٽنگ سسٽم ۾ پيڪيجز جي وچ ۾ انحصار جي تعداد جي تقسيم کي ڏسو:

جوڙ. 4

تقريبن سڀني تقسيم ۾، 60 سيڪڙو پيڪيجز ۾ گهٽ ۾ گهٽ 10 انحصار آهن. ان کان علاوه، ڪجهه پيڪيجز ۾ انحصار جو تمام وڏو تعداد آهي (100 کان وڌيڪ). ساڳيو ئي ريورس پيڪيج جي انحصار تي لاڳو ٿئي ٿو: جيئن توقع ڪئي وئي آهي، ڪجهه پيڪيجز استعمال ڪيا ويا آهن ڪيترن ئي ٻين پيڪيجز طرفان ورڇ ۾، تنهنڪري انهن مان ڪجهه چونڊيل خطرن ۾ وڌيڪ خطرو آهي. مثال طور، هيٺ ڏنل جدول 20 پيڪيجز کي لسٽ ڪري ٿو SLES، Centos 7، Debian 9 ۽ Ubuntu 18.04 ۾ ريورس انحصار جي وڌ ۾ وڌ تعداد سان (هر سيل اشارو ڪري ٿو پيڪيج ۽ ريورس انحصار جو تعداد).

ٽيبل 3

دلچسپ حقيقت. جيتوڻيڪ سڀ او ايسز جو تجزيو ڪيو ويو آهي x86_64 آرڪيٽيڪچر لاءِ، ۽ اڪثر پيڪيجز ۾ آرڪيٽيڪچر کي x86_64 ۽ x86 طور بيان ڪيو ويو آهي، پيڪيجز اڪثر ڪري ٻين آرڪيٽيڪچرز لاءِ بائنري تي مشتمل هوندا آهن، جيئن تصوير 5 ۾ ڏيکاريل آهي. XNUMX.

جوڙ. 5

ايندڙ حصي ۾، اسان تجزيي بائنري جي خاصيتن تي غور ڪنداسين.

بائنري فائل تحفظ جا انگ اکر

بلڪل گهٽ ۾ گهٽ، توهان کي ڳولڻ جي ضرورت آهي بنيادي سيٽ سيڪيورٽي اختيارن جي توهان جي موجوده بائنري لاء. ڪيترائي لينڪس ڊويزنون اسڪرپٽ سان گڏ اچن ٿيون جيڪي اهڙيون چيڪون انجام ڏين ٿيون. مثال طور، Debian/Ubuntu وٽ اهڙي رسم الخط آهي. هتي سندس ڪم جو هڪ مثال آهي:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

اسڪرپٽ پنج چيڪ ڪري ٿو حفاظتي افعال:

• پوزيشن Independent Executable (PIE): ظاهر ڪري ٿو ته ڇا پروگرام جي ٽيڪسٽ سيڪشن کي ميموري ۾ منتقل ڪري سگھجي ٿو randomization حاصل ڪرڻ لاءِ جيڪڏهن ASLR ڪنيل ۾ فعال آهي.
• اسٽيڪ محفوظ ٿيل: ڇا اسٽيڪ ڪينريون چالو ڪيون ويون آھن اسٽيڪ ڪوليشن حملن کان بچاءُ لاءِ.
• Fortify Source: ڇا غير محفوظ افعال (مثال طور، strcpy) انهن جي وڌيڪ محفوظ هم منصبن سان تبديل ڪيا ويا آهن، ۽ رن ٽائم تي چيڪ ڪيل ڪالون انهن جي اڻ چيڪ ٿيل هم منصبن سان تبديل ڪيون وينديون آهن (مثال طور، memcpy بدران __memcpy_chk).
• صرف پڙهڻ لاءِ ريلوڪيشنز (RELRO): ڇا ريلوڪيشن ٽيبل جي داخلائن کي صرف پڙهڻ لاءِ نشان لڳايو ويو آهي جيڪڏهن اهي عمل شروع ٿيڻ کان اڳ شروع ڪيا وڃن.
• فوري پابند: ڇا رن ٽائم لنڪر پروگرام جي عمل شروع ٿيڻ کان اڳ سڀني حرڪتن جي اجازت ڏئي ٿو (اهو مڪمل RELRO جي برابر آهي).

ڇا مٿي ڏنل ميکانيزم ڪافي آهن؟ بدقسمتي سان نه. مٿي ڄاڻايل مڙني دفاعن کي نظرانداز ڪرڻ جا طريقا معلوم ٿين ٿا، پر دفاع جيتري سخت، حملي آور لاءِ بار اوترو وڌيڪ. مثال طور، RELRO بائي پاس طريقا لاڳو ڪرڻ وڌيڪ ڏکيو آهي جيڪڏهن PIE ۽ فوري پابند اثر ۾ آهن. ساڳئي طرح، مڪمل ASLR ڪم ڪندڙ استحصال پيدا ڪرڻ لاء اضافي ڪم جي ضرورت آهي. بهرحال، نفيس حملو ڪندڙ اڳ ۾ ئي تيار آهن اهڙين حفاظتن کي پورا ڪرڻ لاءِ: انهن جي غير موجودگي لازمي طور تي هيڪ کي تيز ڪندي. تنهن ڪري اهو ضروري آهي ته انهن قدمن کي ضروري سمجهيو وڃي گهٽ ۾ گهٽ.

اسان اهو مطالعو ڪرڻ چاهيون ٿا ته سوال ۾ تقسيم ۾ ڪيتريون بائنري فائلون محفوظ آهن انهن ۽ ٽن ٻين طريقن سان:

• ناقابل عمل بٽ (NX) ڪنهن به علائقي ۾ عملدرآمد کي روڪي ٿو جيڪو قابل عمل نه هجڻ گهرجي، جهڙوڪ اسٽيڪ هيپ وغيره.
• RPATH/RUNPATH ملندڙ لائبريرين کي ڳولڻ لاءِ متحرڪ لوڊر پاران استعمال ٿيل عمل جي رستي کي ظاهر ڪري ٿو. پهريون آهي واجب ڪنهن به جديد سسٽم لاءِ: ان جي غير موجودگي حملي ڪندڙن کي اجازت ڏئي ٿي ته هو پنهنجي مرضيءَ سان پيل لوڊ کي ميموري ۾ لکن ۽ ان تي عمل ڪري. ٻئي لاءِ، غلط ايگزيڪيوشن واٽ جي ترتيب ناقابل اعتبار ڪوڊ متعارف ڪرائڻ ۾ مدد ڪري ٿي جيڪا ڪيترن ئي مسئلن کي جنم ڏئي سگھي ٿي (مثال طور. استحقاق جي واڌ، انهي سان گڏوگڏ ٻيا مسئلا).
• اسٽيڪ ڪوليشن تحفظ انهن حملن جي خلاف تحفظ فراهم ڪري ٿو جيڪي اسٽيڪ کي ميموري جي ٻين علائقن کي اوورليپ ڪرڻ جو سبب بڻائين ٿا (جهڙوڪ هيپ). ڏنو تازو استحصال بدسلوڪي سسٽمڊ هيپ تصادم جي ڪمزورين، اسان محسوس ڪيو ته هن ميکانيزم کي اسان جي ڊيٽا سيٽ ۾ شامل ڪرڻ مناسب هو.

تنهن ڪري، وڌيڪ ادو کان سواء، اچو ته نمبرن تي وڃو. جدول 4 ۽ 5 تي مشتمل آهي تجزياتي فائلن جي تجزيي جو خلاصو ۽ مختلف تقسيم جي لائبريرين، ترتيب سان.

• جئين توهان ڏسي سگهو ٿا، NX تحفظ هر جڳهه تي لاڳو ڪيو ويو آهي، نادر استثنا سان. خاص طور تي، ھڪڙو نوٽ ڪري سگھي ٿو ان جو ٿورڙو گھٽ استعمال Ubuntu ۽ Debian تقسيم ۾ CentOS، RHEL ۽ OpenSUSE جي مقابلي ۾.
• اسٽيڪ ڪينري ڪيترن ئي هنڌن تي غائب آهن، خاص طور تي پراڻن ڪنلن سان ورهائڻ ۾. سينوس، RHEL، Debian ۽ Ubuntu جي تازي تقسيم ۾ ڪجهه ترقي ڏٺو پيو وڃي.
• Debian ۽ Ubuntu 18.04 جي استثنا سان، اڪثر تقسيم غريب PIE سپورٽ آهن.
• OpenSUSE، Centos 7 ۽ RHEL 7 ۾ اسٽيڪ ڪوليشن تحفظ ڪمزور آھي، ۽ ٻين ۾ عملي طور تي غير موجود آھي.
• جديد ڪرنل سان سڀني تقسيمن کي RELRO لاءِ ڪجهه مدد حاصل آهي ، Ubuntu 18.04 جي اڳواڻي ۾ ۽ ڊيبين سيڪنڊ ۾ اچي رهيو آهي.

جيئن اڳ ۾ ئي ذڪر ڪيو ويو آهي، هن جدول ۾ ميٽرڪس بائنري فائل جي سڀني نسخن لاء اوسط آهن. جيڪڏهن توهان صرف فائلن جي جديد ورزن تي نظر رکون ٿا، انگ مختلف هوندا (مثال طور، ڏسو ڊيبين جي ترقي PIE عمل درآمد سان). ان کان علاوه، اڪثر تقسيم عام طور تي بائنري ۾ صرف چند افعال جي سيڪيورٽي کي جانچيندا آهن جڏهن انگن اکرن جي حساب سان، پر اسان جو تجزيو ڏيکاري ٿو حقيقي فيصد افعال جو جيڪو سخت آهي. تنهن ڪري، جيڪڏهن 5 مان 50 افعال هڪ بائنري ۾ محفوظ آهن، اسان ان کي 0,1 جو اسڪور ڏينداسين، جيڪو 10 سيڪڙو افعال کي مضبوط ڪيو وڃي ٿو.

ٽيبل 4. ايگزيڪيوٽيبل فائلن لاءِ حفاظتي خاصيتون تصوير ۾ ڏيکاريل آهن. 3 (ملندڙ عملن جو عمل درآمد ڪرڻ واري فائلن جي ڪل تعداد جي سيڪڙو جي طور تي)

جدول 5. تصوير ۾ ڏيکاريل لائبريرين لاءِ حفاظتي خاصيتون. 3 (لائبرريءَ جي ڪل تعداد جي سيڪڙو جي طور تي لاڳاپيل ڪمن جو نفاذ)

پوء اتي ترقي آهي؟ هتي ضرور آهي: اهو انفرادي تقسيم جي انگن اکرن مان ڏسي سگهجي ٿو (مثال طور، ديبين)، گڏوگڏ مٿي ڏنل جدولن مان. مثال طور تصوير ۾. شڪل 6 Ubuntu LTS 5 جي ٽن لڳاتار تقسيم ۾ تحفظ واري ميڪانيزم جي نفاذ کي ڏيکاري ٿو (اسان اسٽيڪ ٽوڙ تحفظ واري انگ اکر کي ختم ڪيو آهي). اسان نوٽيس ڪريون ٿا ته نسخي کان نسخن تائين وڌيڪ ۽ وڌيڪ فائلون اسٽيڪ ڪنريز کي سپورٽ ڪن ٿيون، ۽ وڌيڪ ۽ وڌيڪ بائنري مڪمل RELRO تحفظ سان موڪليا ويا آهن.

جوڙ. 6

بدقسمتي سان، مختلف تقسيم ۾ قابل عمل فائلن جو تعداد اڃا تائين مٿي ڏنل تحفظن مان نه آهي. مثال طور، Ubuntu 18.04 کي ڏسي، توهان ڏسندا ngetty بائنري (هڪ گٽي متبادل)، انهي سان گڏ mksh ۽ lksh شيل، picolisp مترجم، nvidia-cuda-toolkit پيڪيجز (GPU-accelerated ايپليڪيشنن لاءِ هڪ مشهور پيڪيج. جهڙوڪ مشين لرننگ فريم ورڪ)، ۽ klibc -utils. اهڙي طرح، مينڊوس ڪلائنٽ بائنري (هڪ انتظامي اوزار جيڪو توهان کي خودڪار طريقي سان ريبوٽ ڪرڻ جي اجازت ڏئي ٿو اينڪرپٽ فائل سسٽم سان) ۽ انهي سان گڏ rsh-redone-client (rsh ۽ rlogin جو ٻيهر لاڳو ڪرڻ) بغير NX تحفظ جي ٻيڙي، جيتوڻيڪ اهي آهن SUID حق: (. انهي سان گڏ، ڪيترائي سوڊ بائنري بنيادي تحفظ کان محروم آهن جهڙوڪ اسٽيڪ ڪينريز (مثال طور، Xorg پيڪيج مان Xorg.wrap بائنري).

خلاصو ۽ اختتامي تبصرا

هن آرٽيڪل ۾، اسان نمايان ڪيو آهي ڪيترن ئي حفاظتي خاصيتن جي جديد لينڪس جي تقسيم. تجزيي ڏيکاري ٿي ته جديد Ubuntu LTS تقسيم (18.04) لاڳو ڪري ٿو، سراسري طور تي، مضبوط ترين او ايس ۽ ايپليڪيشن سطح جي تحفظ کي تقسيم جي وچ ۾ نسبتا نئين ڪنلن سان، جهڙوڪ Ubuntu 14.04، 12.04 ۽ Debian 9. جڏهن ته، جانچيل تقسيم CentOS، RHEL ۽ OpenSUSE اسان جي سيٽ ۾ ڊفالٽ طور تي اهي پيڪيجز جو هڪ denser سيٽ ٺاهيندا آهن، ۽ جديد نسخن ۾ (CentOS ۽ RHEL) انهن وٽ ڊيبين جي بنياد تي مقابلن (Debian ۽ Ubuntu) جي مقابلي ۾ اسٽيڪ ٽڪر جي حفاظت جو اعلي سيڪڙو آهي. CentOS ۽ RedHat ورزن جي مقابلي ۾، اسان اسٽيڪ ڪينريز ۽ RELRO جي ورزن 6 کان 7 تائين لاڳو ڪرڻ ۾ وڏيون واڌايون محسوس ڪيون ٿا، پر سراسري طور تي CentOS ۾ RHEL کان وڌيڪ خاصيتون لاڳو ٿيل آھن. عام طور تي، سڀني تقسيم کي PIE تحفظ تي خاص ڌيان ڏيڻ گهرجي، جيڪو، Debian 9 ۽ Ubuntu 18.04 جي استثنا سان، اسان جي ڊيٽا سيٽ ۾ بائنري جي 10٪ کان گهٽ ۾ لاڳو ٿئي ٿو.

آخرڪار، اهو ياد رکڻ گهرجي ته جيتوڻيڪ اسان تحقيق دستي طور تي ڪيو، اتي ڪيترائي حفاظتي اوزار موجود آهن (مثال طور. Lynis, چيتي, هبل)، جيڪو تجزيو انجام ڏئي ٿو ۽ غير محفوظ ترتيبن کان بچڻ ۾ مدد ڪري ٿو. بدقسمتي سان، مناسب ترتيبن ۾ اڃا به مضبوط تحفظ استحصال جي غير موجودگي جي ضمانت نٿو ڏئي. ان ڪري اسان يقين رکون ٿا ته ان کي يقيني بڻائڻ ضروري آهي حقيقي وقت ۾ حملن جي قابل اعتماد نگراني ۽ روڪٿاماستحصال جي نمونن تي ڌيان ڏيڻ ۽ انهن کي روڪڻ.

جو ذريعو: www.habr.com