به‌سوی امنیت

حملاتی که به سیستم‌های عامل انجام می‌شود، به‌طور کلی حافظه و مشکلات مدیریت آن را هدف می‌گیرند و در واقع، تخریب حافظه یکی از راه‌های معمول برای نفوذ به سیستم‌های کامپیوتری مدرن است. ماجرا از این قرار است که یک سرریزی بافر می‌تواند کار را به حملات پیچیده تخریب حافظه بکشاند و نظام یکپارچه پروسه‌‌ها و حافظه سیستم را به‌هم بزند.

امنیت سیستم‌ها هر چند که در طول سالیان مختلف و از هر نگارش به نگارش بعدی بهبود یافته است، اما تکنیک‌های هجوم به این بخش از سیستم در طول زمان پیچیده‌تر شده و در توزیع‌های مختلف لینوکس برای آزمون امنیت به‌کار می‌رود. بسیاری از کارشناسان معتقدند برخی از مکانیزم‌های امنیت در مقایسه با دیگر روش‌ها، مقاوم‌تر هستند. علاوه بر این، تعدادی از این روش‌ها تاثیر زیادی روی بازدهی سیستم می‌گذارند و حتی می‌توانند هنگام کامپایل نرم‌افزاری خاص،‌ از نظر تطبیق با سیستم مشکل‌ساز شوند.

می‌توان اشاره کرد که این دو فاکتور، یعنی تاثیر در بازدهی سیستم و امکان از دست رفتن کنترل روی نگهداری سیستم، بزرگ‌ترین دغدغه‌هایی است که تمام مکانیزم‌ها و روش‌های مقاومت در برابر حفره‌های امنیتی در توزیع‌های لینوکس با آن مواجهند. در هر نرم‌افزار و توسعه نرم‌افزاری آن می‌توان بدون هیچ تعجبی مشاهده کرد که این مساله حتی می‌تواند بحث‌های شدیدتری بین چندین پروژه به‌وجود بیاورد (همان‌طور که بحث‌های زیادی میان اعضای پروژه Grsecurity و تیم توسعه هسته لینوکس‌ به‌وجود آمد).

با این وجود، در این مقاله تلاش شده است تا بین 5توزیع محبوب لینوکس، دبیان، فدورا، اوبونتو، اوپن‌سوسه و جنتوهاردند مقایسه‌ای از نظر پیاده‌سازی مکانیزم‌های محافظت انجام شود. 4 توزیع نخست بسیار پرکاربرد هستند و جنتو به‌عنوان توزیع میزان برای به‌دست آوردن دیدگاهی از یک توزیع امن انتخاب شده است.

مکانیزم‌های امنیتی که در این مقایسه انجام شده، به‌صورت زیر است:

- نگاشت حافظه غیر‌اجرایی (استفاده از بیت سخت‌افزاری NX)

- کد یا برنامه مستقل از محل (PIC/PIE)

- پیاده‌سازی قابلیت FORTIFY_SOURCE از glibc

- محافظت از نابودی پشته (SSP)

- RELRO یا محکم کردن برنامه‌های ELF با مرتب‌سازی بخش‌هایی از فایل و تبدیل آنها به حالت فقط‌خواندنی.

همچنین ابزارهای زیر برای مقایسه استفاده شد:‌

- checksec.sh – با اصلاح کوچکی که وضعیت FORTIFY_SOURCE را نشان دهد.

- اسکریپت پایتونی که قابلیت‌های checksec.sh را افزایش می‌دهد.

داده‌های آزمایش نیز از طریق کاربری که وارد سیستم X شده و یک دمون sshd و مرورگر فایرفاکس را اجرا کرده، گرد‌آوری شده است. از آنجا که برخی از توزیع‌ها نسبت به دیگران هنگام اجرا تعداد پروسه‌های مختلفی دارند (مثلا اوبونتو 96 و جنتو تنها 34 پروسه دارد)، این اقدام باعث می‌شود که نتایج یکسان دربیاید.

در ویکی‌پدیا آمده است که هسته لینوکس بیت NX را از زمان توزیع 8/6/2 پشتیبانی کرده است. از این‌رو برای سخت‌افزارهای 32 و 64بیتی که این بیت را در مدار خود دارند، فعال است. برای بهره بردن از نگاشت حافظه غیراجرایی در سخت‌افزارهایی که از این قابلیت استفاده نمی‌کنند، لازم است که وصله grsecurity یا بسته Exec Shield را از رد هت دریافت کنید. همچنین باید اشاره شود که بدون محافظت اضافه، مهاجم به‌سادگی می‌تواند بیت NX را دور بزند و دسترسی‌ها را به‌صورت دستی تنظیم کند. از آنجا که این مساله به هسته لینوکس برمی‌گردد در شماره‌های آینده در مورد آن صحبت خواهد شد.

همچنین باید اشاره شود که به‌جز بیت NX، تمام مکانیزم‌های امنیتی که در این مقاله به آن اشاره شده است در بخش فضای کاربری حافظه پیاده‌سازی شده‌اند و در سطح هسته نیستند. همچنین مهم است بدانیم حفره‌ای که در هسته لینوکس وجود دارد، صرف نظر از مکانیزم‌های امنیتی که برای پروسس‌های فضای کاربر فعال شده است، می‌تواند مورد تهاجم قرار بگیرد. از این‌رو می‌توان هسته‌های سیستم عامل امروزی را با پشتیبانی نابودی پشته کامپایل کرد، هرچند بهبود امنیت هسته اغلب به نصب وصله‌های زیادی از جمله وصله grsecurity منجر می‌شود. برخی از توزیع‌ها برای خود وصله‌های خاص امنیتی منتشر می‌کنند.

حفاظت ساختمان داده داخلی یک فایل ELF بر عهده RELRO است تا نگذارد اطلاعات آن را مهاجم ببیند یا جریان اجرای آن را کنترل کند. این امنیت را با اصلاح جدول اتصال روندها (PLT) یا جدول عمومی آفست‌ها (GOT) که بخشی از فایل ELF است، تضمین می‌کنند.

وقتی RELRO استفاده می‌شود، کل بخش GOT به حالت فقط‌خواندنی تغییر پیدا می‌کند و از این رو وقتی پروسس اجرا می‌شود نمی‌تواند توسط هیچ مهاجمی قابل تغییر باشد. اگر RELRO به‌صورت جزیی پیاده‌سازی شود، فقط PLT و GOT به‌عنوان فقط‌خواندنی علامت زده می‌شوند. هر دوی این گزینه‌ها البته ساختمان داده ELF را از نو مرتب می‌کنند تا مهاجم نتواند این بخش‌ها را با بخش‌های دیگر ELF روی هم بیندازد.

همچنین لازم به ذکر است که RELRO کاملا نیازمند آن است که تمامی سمبل‌ها هنگام اجرای برنامه شناسایی شود تا بتوان کل GOT را به‌صورت فقط خواندنی در آورد. از این رو برنامه‌های بزرگ‌تر با کندی بیشتری هنگام بازشدن روبه‌رو می‌شوند و تعداد زیادی از سمبل‌ها از کتابخانه‌های اشتراک‌یافته باید بارگذاری شوند.

همان‌طور که در شکل نیز اشاره شده است، دبیان و فدورا هنوز به‌طور کامل این مکانیزم را پیاده نکرده‌اند و برای درصد اندکی از باینری‌های خود، به‌صورت جزیی آن را فعال کرده‌اند. در مثال ما فدورا و دبیان برای هیچ کدام از برنامه‌هایی که به‌صورت پیش‌فرض اجرا می‌شوند، آن را فعال نکرده بودند. از سوی دیگر، اوبونتو و اوپن‌سوسه RELRO را به‌صورت جزیی برای تمام پروسس‌ها فعال و RELRO کامل را برای بخشی از آنها فعال کرده‌اند. جنتو RELRO را به‌طور کامل برای تمام برنامه‌ها به‌جز یکی فعال کرده است که آن هم به‌صورت جزیی RELRO دارد.

از سوی دیگر تنها باینری‌ای که در اوپن‌سوسه قابلیت RELRO کامل را داشت، pulseaudio بود.

محافظ خرابی پشته سوء استفاده از سرریزی بافر را با پیاده‌سازی بررسی‌های امنیتی بیشتر در پروسس پشته دشوارتر می‌کند. افزونه SSP در کامپایلر GCC از زمان نگارش 1/4 به این برنامه اضافه شد.

همان‌طور که در نمودار بالا می‌توان مشاهده کرد، فدورا، اوپن‌سوسه و اوبونتو نتیجه‌ای به‌نسبت مساوی دارند و تقریبا 80 درصد از این توزیع‌ها، این قابلیت را برای پروسس‌های خود فعال کرده‌اند. تفاوت‌های قابل مشاهده در دبیان و جنتو وجود دارد و 10درصد از پروسس‌ها این مکانیزم را فعال کرده‌اند. در مورد جنتو باید گفت که این مساله یک مشکل داخلی بود که اول باید آن را برطرف می‌کردند و بعد این قابلیت را به‌صورت کلی در سیستم پیاده می‌کردند. گفتنی است که در نگارش بعدی جنتو و کامپایلر gcc، این قابلیت آزموده و فعال شده است و احتمالا در به‌روز‌رسانی بعدی gcc‌ به سیستم اضافه شود.

محمدرضا قربانی
منبع: mwrinfosecurity