TL؛ DR. در این مقاله، طرح‌های سخت‌سازی را بررسی می‌کنیم که در پنج توزیع محبوب لینوکس کار می‌کنند. برای هر کدام، پیکربندی هسته پیش‌فرض را گرفتیم، همه بسته‌ها را بارگذاری کردیم و طرح‌های امنیتی را در باینری‌های پیوست شده آنالیز کردیم. توزیع های در نظر گرفته شده عبارتند از OpenSUSE 12.4، Debian 9، CentOS، RHEL 6.10 و 7، و همچنین Ubuntu 14.04، 12.04 و 18.04 LTS.

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

بررسی نشان داد که بیشترین تعداد روش‌های حفاظتی در اوبونتو 18.04 در سطوح سیستم‌عامل و برنامه‌های کاربردی و به دنبال آن Debian 9 اجرا شده است. از سوی دیگر، OpenSUSE 12.4، CentOS 7 و RHEL 7 نیز طرح‌های حفاظتی اولیه و حفاظت از برخورد پشته را پیاده‌سازی می‌کنند. با مجموعه ای بسیار متراکم تر از بسته های پیش فرض حتی به طور گسترده تر استفاده می شود.

معرفی

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

اینجاست که روش های محافظت یا سخت کردن برنامه ها وارد عمل می شوند. ما نمی‌توانیم از برخی از انواع خطاها جلوگیری کنیم، اما می‌توانیم زندگی مهاجم را دشوارتر کنیم و با پیشگیری یا پیشگیری، مشکل را تا حدی حل کنیم. بهره برداری این خطاها چنین حفاظتی در تمام سیستم عامل های مدرن استفاده می شود، اما روش ها در پیچیدگی، کارایی و عملکرد بسیار متفاوت هستند: از قناری های پشته ای و ASLR برای محافظت کامل CFI и ROP. در این مقاله به بررسی روش‌های حفاظتی در محبوب‌ترین توزیع‌های لینوکس در پیکربندی پیش‌فرض می‌پردازیم و همچنین ویژگی‌های باینری‌هایی که از طریق سیستم‌های مدیریت بسته هر توزیع توزیع می‌شوند را بررسی می‌کنیم.

CVE و امنیت

همه ما مقالاتی را با عناوینی مانند "آسیب پذیرترین برنامه های سال" یا "آسیب پذیرترین سیستم عامل ها" دیده ایم. معمولاً آنها آماری از تعداد کل سوابق مربوط به آسیب پذیری هایی مانند CVE (آسیب‌پذیری و مواجهه‌های رایج)، بدست آمده از پایگاه ملی آسیب پذیری (NVD) از NIST و منابع دیگر پس از آن، این برنامه ها یا سیستم عامل ها بر اساس تعداد CVE رتبه بندی می شوند. متأسفانه، در حالی که CVE ها برای ردیابی مسائل و اطلاع رسانی به فروشندگان و کاربران بسیار مفید هستند، در مورد امنیت واقعی نرم افزار چیزی نمی گویند.

به عنوان مثال، تعداد کل CVE ها را در چهار سال گذشته برای هسته لینوکس و پنج توزیع سرور محبوب، یعنی Ubuntu، Debian، Red Hat Enterprise Linux و OpenSUSE در نظر بگیرید.

شکل 1

این نمودار به ما چه می گوید؟ آیا تعداد بیشتر CVE به این معنی است که یک توزیع نسبت به دیگری آسیب پذیرتر است؟ بدون پاسخ. به عنوان مثال، در این مقاله خواهید دید که دبیان مکانیسم های امنیتی قوی تری نسبت به مثلا OpenSUSE یا RedHat Linux دارد و با این حال دبیان CVE های بیشتری دارد. با این حال، آنها لزوماً به معنای تضعیف امنیت نیستند: حتی وجود یک CVE نشان نمی دهد که آیا یک آسیب پذیری وجود دارد یا خیر. مورد بهره برداری قرار گرفت. نمرات شدت نشان می دهد که چگونه احتمالاً بهره برداری از یک آسیب پذیری، اما در نهایت قابلیت بهره برداری به شدت به حفاظت های موجود در سیستم های آسیب دیده و منابع و قابلیت های مهاجمان بستگی دارد. علاوه بر این، عدم وجود گزارش های CVE چیزی در مورد دیگران نمی گوید ثبت نشده یا ناشناخته آسیب پذیری ها تفاوت در CVE ممکن است به دلیل عواملی غیر از کیفیت نرم افزار، از جمله منابع تخصیص یافته به آزمایش یا اندازه پایگاه کاربر باشد. در مثال ما، تعداد بیشتر CVE های دبیان ممکن است به سادگی نشان دهد که دبیان بسته های نرم افزاری بیشتری را ارسال می کند.

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

شکل 2

وظایف

در این مقاله قصد داریم به سوالات زیر پاسخ دهیم:

• امنیت توزیع های مختلف لینوکس چیست؟ چه مکانیسم های حفاظتی در برنامه های هسته و فضای کاربر وجود دارد؟
• پذیرش مکانیسم های امنیتی در طول زمان در سراسر توزیع ها چگونه تغییر کرده است؟
• میانگین وابستگی بسته ها و کتابخانه ها برای هر توزیع چقدر است؟
• چه حفاظت هایی برای هر باینری اجرا می شود؟

انتخاب توزیع ها

به نظر می رسد که یافتن آمار دقیق در مورد نصب های توزیع دشوار است، زیرا در بیشتر موارد تعداد دانلودها تعداد نصب های واقعی را نشان نمی دهد. با این حال، انواع یونیکس اکثر سیستم های سرور را تشکیل می دهند (در سرورهای وب 69,2٪ آمار W3techs و منابع دیگر)، و سهم آنها به طور مداوم در حال افزایش است. بنابراین، ما برای تحقیق خود بر توزیع‌های موجود خارج از جعبه در پلتفرم تمرکز کردیم Google Cloud. به طور خاص، ما سیستم عامل زیر را انتخاب کردیم:

توزیع/نسخه
هسته
ساختن

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 Debian 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 Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
# 1 SMP چهارشنبه 21 نوامبر 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
# 1 SMP پنجشنبه 15 نوامبر 17:36:42 UTC 2018

اوبونتو 14.04 (Trusty Tahr)
4.4.0-140-عمومی

#166~14.04.1-اوبونتو SMP شنبه 17 نوامبر 01:52:43 UTC 20…

اوبونتو 16.04 (Xenial Xerus)
4.15.0-1026-gcp
#27~16.04.1-اوبونتو SMP جمعه 7 دسامبر 09:59:47 UTC 2018

اوبونتو 18.04 (بیونیک بیور)
4.15.0-1026-gcp
#27-اوبونتو SMP پنجشنبه 6 دسامبر 18:27:01 UTC 2018

جدول 1

تحلیل

بیایید پیکربندی هسته پیش‌فرض و همچنین ویژگی‌های بسته‌های موجود از طریق مدیر بسته هر توزیع را در خارج از جعبه مطالعه کنیم. بنابراین، ما فقط بسته‌هایی را از آینه‌های پیش‌فرض هر توزیع در نظر می‌گیریم، بسته‌های موجود در مخازن ناپایدار (مانند آینه‌های «تست» دبیان) و بسته‌های شخص ثالث (مانند بسته‌های Nvidia از آینه‌های استاندارد) را نادیده می‌گیریم. علاوه بر این، ما کامپایل‌های هسته سفارشی یا پیکربندی‌های سخت‌شده امنیتی را در نظر نمی‌گیریم.

تجزیه و تحلیل پیکربندی هسته

ما یک اسکریپت تحلیل را بر اساس آن اعمال کردیم جستجوگر kconfig رایگان. بیایید به پارامترهای حفاظتی خارج از جعبه توزیع های نامگذاری شده نگاهی بیندازیم و آنها را با لیستی از پروژه دفاع شخصی اصلی (KSPP). برای هر گزینه پیکربندی، جدول 2 تنظیمات مورد نظر را توضیح می دهد: چک باکس برای توزیع هایی است که با توصیه های KSSP مطابقت دارند (برای توضیح اصطلاحات به موارد زیر مراجعه کنید). اینجا; در مقالات بعدی توضیح خواهیم داد که چه تعداد از این روش های امنیتی به وجود آمده اند و چگونه می توان یک سیستم را در غیاب آنها هک کرد).

به طور کلی، هسته های جدید تنظیمات سخت گیرانه تری دارند. به عنوان مثال، CentOS 6.10 و RHEL 6.10 در هسته 2.6.32 فاقد اکثر ویژگی های حیاتی پیاده سازی شده در هسته های جدیدتر مانند SMAP، مجوزهای سختگیرانه RWX، تصادفی سازی آدرس یا محافظت از copy2usr. لازم به ذکر است که بسیاری از گزینه های پیکربندی موجود در جدول در نسخه های قدیمی هسته موجود نیستند و در واقعیت قابل اجرا نیستند - این هنوز در جدول به عنوان عدم وجود محافظت مناسب نشان داده شده است. به همین ترتیب، اگر یک گزینه پیکربندی در یک نسخه مشخص وجود نداشته باشد، و امنیت مستلزم غیرفعال کردن آن گزینه باشد، این یک پیکربندی معقول در نظر گرفته می شود.

نکته دیگری که هنگام تفسیر نتایج باید در نظر گرفت: برخی از پیکربندی‌های هسته که سطح حمله را افزایش می‌دهند نیز می‌توانند برای امنیت استفاده شوند. چنین نمونه هایی عبارتند از uprobes و kprobe، ماژول های هسته و BPF/eBPF. توصیه ما این است که از مکانیسم‌های فوق برای ارائه حفاظت واقعی استفاده کنید، زیرا استفاده از آنها بی‌اهمیت است و سوءاستفاده از آنها فرض می‌کند که عوامل مخرب قبلاً جای پایی در سیستم ایجاد کرده‌اند. اما اگر این گزینه ها فعال باشند، مدیر سیستم باید به طور فعال برای سوء استفاده نظارت کند.

با نگاهی بیشتر به ورودی‌های جدول 2، می‌بینیم که هسته‌های مدرن چندین گزینه برای محافظت در برابر سوء استفاده از آسیب‌پذیری‌ها مانند نشت اطلاعات و سرریزهای پشته/هپ ارائه می‌دهند. با این حال، ما متوجه شده ایم که حتی جدیدترین توزیع های محبوب هنوز محافظت پیچیده تری را اجرا نکرده اند (مثلاً با وصله ها) grsecurity) یا محافظت مدرن در برابر حملات استفاده مجدد از کد (به عنوان مثال. ترکیبی از تصادفی سازی با طرح هایی مانند R^X برای کد). بدتر از آن، حتی این دفاع های پیشرفته تر در برابر طیف وسیعی از حملات محافظت نمی کنند. بنابراین، برای مدیران سیستم ضروری است که پیکربندی های هوشمند را با راه حل هایی تکمیل کنند که شناسایی و پیشگیری از سوء استفاده در زمان اجرا را ارائه می دهد.

تجزیه و تحلیل برنامه

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

توزیع ها

در مجموع، ما 361 بسته را برای همه توزیع‌ها دانلود کردیم و فقط بسته‌ها را از آینه‌های پیش‌فرض استخراج کردیم. ما بسته‌های بدون فایل‌های اجرایی ELF را نادیده گرفتیم. توزیع بسته ها و فایل ها در بین توزیع ها در شکل 556 نشان داده شده است. 129.

شکل 3

ممکن است متوجه شوید که هرچه توزیع مدرن تر باشد، بسته ها و باینری های بیشتری در آن وجود دارد، که منطقی است. با این حال، بسته‌های اوبونتو و دبیان شامل تعداد بیشتری باینری (هم اجرایی و هم ماژول‌ها و کتابخانه‌های پویا) نسبت به CentOS، SUSE و RHEL هستند که به طور بالقوه بر سطح حمله اوبونتو و دبیان تأثیر می‌گذارد (لازم به ذکر است که اعداد همه باینری‌های همه نسخه‌ها را منعکس می‌کنند. بسته، یعنی برخی از فایل ها چندین بار تجزیه و تحلیل می شوند). این امر به ویژه هنگامی که وابستگی بین بسته ها را در نظر می گیرید بسیار مهم است. بنابراین، یک آسیب‌پذیری در یک بسته باینری می‌تواند بسیاری از بخش‌های اکوسیستم را تحت تأثیر قرار دهد، همانطور که یک کتابخانه آسیب‌پذیر می‌تواند بر همه باینری‌هایی که آن را وارد می‌کنند، تأثیر بگذارد. به عنوان نقطه شروع، بیایید به توزیع تعداد وابستگی ها در بین بسته ها در سیستم عامل های مختلف نگاه کنیم:

شکل 4

تقریباً در همه توزیع‌ها، 60 درصد بسته‌ها حداقل 10 وابستگی دارند. علاوه بر این، برخی از بسته ها دارای تعداد قابل توجهی وابستگی بیشتری هستند (بیش از 100). همین امر در مورد وابستگی‌های بسته معکوس نیز صدق می‌کند: همانطور که انتظار می‌رود، تعداد کمی از بسته‌ها توسط بسیاری از بسته‌های دیگر در توزیع استفاده می‌شوند، بنابراین آسیب‌پذیری‌ها در آن تعداد کمی از بسته‌ها ریسک بالایی دارند. به عنوان مثال، جدول زیر 20 بسته با حداکثر تعداد وابستگی معکوس در SLES، Centos 7، Debian 9 و Ubuntu 18.04 را فهرست می کند (هر سلول نشان دهنده بسته و تعداد وابستگی های معکوس است).

جدول 3

حقیقت جالب. اگرچه تمام سیستم‌عامل‌های تحلیل‌شده برای معماری x86_64 ساخته شده‌اند، و اکثر بسته‌ها دارای معماری تعریف شده به عنوان x86_64 و x86 هستند، بسته‌ها اغلب شامل باینری‌ها برای معماری‌های دیگر هستند، همانطور که در شکل 5 نشان داده شده است. XNUMX.

شکل 5

در بخش بعدی به بررسی ویژگی های باینری های تحلیل شده می پردازیم.

آمار حفاظت از فایل های باینری

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

$ 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

اسکریپت پنج را بررسی می کند توابع حفاظتی:

• قابل اجرا مستقل از موقعیت (PIE): نشان می دهد که اگر ASLR در هسته فعال باشد، بخش متن یک برنامه را می توان در حافظه جابجا کرد تا تصادفی سازی شود.
• Stack Protected: آیا قناری های پشته ای برای محافظت در برابر حملات برخورد پشته فعال هستند یا خیر.
• Fortify Source: آیا توابع ناامن (مثلا strcpy) با همتاهای امن تر خود جایگزین می شوند و تماس هایی که در زمان اجرا بررسی می شوند با همتاهای بدون علامت خود جایگزین می شوند (مثلاً memcpy به جای __memcpy_chk).
• جابجایی‌های فقط خواندنی (RELRO): آیا ورودی‌های جدول جابجایی فقط خواندنی علامت‌گذاری می‌شوند، اگر قبل از شروع اجرا فعال شوند.
• Immediate binding: آیا پیوند دهنده زمان اجرا اجازه می دهد تا همه حرکت ها قبل از شروع اجرای برنامه انجام شود (این معادل یک RELRO کامل است).

آیا مکانیسم های فوق کافی است؟ متاسفانه نه. راه های شناخته شده ای برای دور زدن تمام دفاع های فوق وجود دارد، اما هرچه دفاع سخت تر باشد، میله برای مهاجم بالاتر می رود. مثلا، روش های دور زدن RELRO اگر PIE و اتصال فوری در حال اجرا باشند، اعمال دشوارتر است. به همین ترتیب، ASLR کامل به کار اضافی برای ایجاد یک اکسپلویت کاری نیاز دارد. با این حال، مهاجمان پیچیده در حال حاضر برای مقابله با چنین محافظت هایی آماده هستند: عدم وجود آنها اساساً هک را سرعت می بخشد. بنابراین ضروری است که این اقدامات ضروری تلقی شود کمترین.

ما می‌خواستیم بررسی کنیم که چند فایل باینری در توزیع‌های مورد نظر با این و سه روش دیگر محافظت می‌شوند:

• بیت غیر قابل اجرا (NX) از اجرا در هر منطقه ای که نباید قابل اجرا باشد مانند پشته پشته و غیره جلوگیری می کند.
• RPATH/RUNPATH نشان دهنده مسیر اجرایی است که توسط بارگذار پویا برای یافتن کتابخانه های منطبق استفاده می شود. اولی است اجباری برای هر سیستم مدرن: عدم وجود آن به مهاجمان اجازه می دهد تا به طور دلخواه بار را در حافظه بنویسند و آن را همانطور که هست اجرا کنند. برای دوم، پیکربندی‌های مسیر اجرای نادرست به معرفی کد غیرقابل اعتماد کمک می‌کند که می‌تواند منجر به تعدادی از مشکلات شود (به عنوان مثال. افزایش امتیازو مشکلات دیگر).
• حفاظت از برخورد پشته، محافظت در برابر حملاتی را فراهم می کند که باعث همپوشانی پشته با سایر قسمت های حافظه (مانند پشته) می شود. با توجه به سوء استفاده های اخیر آسیب پذیری های برخورد هیپ سیستمی، ما احساس کردیم مناسب است که این مکانیسم را در مجموعه داده خود لحاظ کنیم.

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

• همانطور که می بینید، حفاظت NX در همه جا اجرا می شود، به استثنای نادر. به طور خاص، می توان به استفاده کمی کمتر از آن در توزیع های اوبونتو و دبیان در مقایسه با CentOS، RHEL و OpenSUSE اشاره کرد.
• قناری های پشته ای در بسیاری از مکان ها، به ویژه در توزیع هایی که هسته های قدیمی تر دارند، وجود ندارند. پیشرفت هایی در آخرین توزیع های Centos، RHEL، Debian و Ubuntu مشاهده می شود.
• به استثنای دبیان و اوبونتو 18.04، اکثر توزیع‌ها پشتیبانی ضعیفی از PIE دارند.
• حفاظت از برخورد پشته در OpenSUSE، Centos 7 و RHEL 7 ضعیف است و در سایرین تقریباً وجود ندارد.
• همه توزیع‌های با هسته‌های مدرن تا حدی از RELRO پشتیبانی می‌کنند، اوبونتو 18.04 پیشتاز است و دبیان در رتبه دوم قرار دارد.

همانطور که قبلا ذکر شد، معیارهای موجود در این جدول میانگین برای تمام نسخه های فایل باینری است. اگر فقط به آخرین نسخه فایل ها نگاه کنید، اعداد متفاوت خواهند بود (به عنوان مثال، ببینید پیشرفت دبیان با پیاده سازی PIE). علاوه بر این، اکثر توزیع‌ها معمولاً هنگام محاسبه آمار، امنیت چند تابع را در باینری آزمایش می‌کنند، اما تجزیه و تحلیل ما درصد واقعی توابع سخت‌شده را نشان می‌دهد. بنابراین، اگر 5 تابع از 50 تابع در یک باینری محافظت شود، به آن امتیاز 0,1 می دهیم که مربوط به 10 درصد از توابع در حال تقویت است.

جدول 4. ویژگی های امنیتی برای فایل های اجرایی نشان داده شده در شکل. 3 (اجرای توابع مربوطه به عنوان درصدی از تعداد کل فایل های اجرایی)

جدول 5. ویژگی های امنیتی برای کتابخانه های نشان داده شده در شکل. 3 (اجرای عملکردهای مربوطه به عنوان درصدی از تعداد کل کتابخانه ها)

پس آیا پیشرفتی وجود دارد؟ قطعاً وجود دارد: این را می توان از آمار توزیع های فردی مشاهده کرد (به عنوان مثال، دبیان) و همچنین از جداول بالا. به عنوان مثال در شکل. شکل 6 اجرای مکانیسم های حفاظتی را در سه توزیع متوالی Ubuntu LTS 5 نشان می دهد (ما آمار حفاظت از برخورد پشته را حذف کرده ایم). ما متوجه شده‌ایم که از نسخه‌ای به نسخه دیگر، فایل‌های بیشتری از Stack canaries پشتیبانی می‌کنند، و همچنین تعداد بیشتری باینری با محافظت کامل RELRO ارسال می‌شوند.

شکل 6

متاسفانه تعدادی از فایل های اجرایی در توزیع های مختلف هنوز هیچ یک از حفاظت های فوق را ندارند. به عنوان مثال، با نگاهی به اوبونتو 18.04، متوجه ngetty باینری (یک جایگزین getty)، و همچنین پوسته‌های mksh و lksh، مفسر picolisp، بسته‌های nvidia-cuda-toolkit (یک بسته محبوب برای برنامه‌های کاربردی با شتاب GPU) خواهید شد. مانند چارچوب های یادگیری ماشین)، و klibc -utils. به همین ترتیب، باینری mandos-client (ابزار مدیریتی که به شما امکان راه‌اندازی خودکار ماشین‌ها با سیستم‌های فایل رمزگذاری‌شده را می‌دهد) و همچنین rsh-redone-client (پیاده‌سازی مجدد rsh و rlogin) بدون محافظت NX ارسال می‌شوند، اگرچه دارای حقوق SUID هستند: (. همچنین، چندین باینری suid فاقد حفاظت اولیه مانند قناری های پشته ای هستند (به عنوان مثال، باینری Xorg.wrap از بسته Xorg).

خلاصه و سخنان پایانی

در این مقاله، چندین ویژگی امنیتی توزیع‌های مدرن لینوکس را برجسته کرده‌ایم. تجزیه و تحلیل نشان داد که آخرین توزیع Ubuntu LTS (18.04) به طور متوسط ​​قوی ترین سیستم عامل و حفاظت از سطح برنامه را در میان توزیع هایی با هسته های نسبتاً جدید، مانند Ubuntu 14.04، 12.04 و Debian 9 پیاده سازی می کند. با این حال، توزیع های مورد بررسی CentOS، RHEL و OpenSUSE در مجموعه ما به طور پیش فرض مجموعه ای متراکم از بسته ها را تولید می کند و در آخرین نسخه ها (CentOS و RHEL) درصد بیشتری از محافظت در برابر برخورد پشته در مقایسه با رقبای مبتنی بر دبیان (دبیان و اوبونتو) دارند. با مقایسه نسخه‌های CentOS و RedHat، متوجه پیشرفت‌های بزرگی در اجرای Stack canaries و RELRO از نسخه‌های 6 تا 7 می‌شویم، اما به طور متوسط ​​CentOS دارای ویژگی‌های بیشتری نسبت به RHEL است. به طور کلی، همه توزیع ها باید توجه ویژه ای به حفاظت از PIE داشته باشند، که به استثنای Debian 9 و Ubuntu 18.04، در کمتر از 10٪ از باینری های مجموعه داده ما پیاده سازی می شود.

در نهایت، لازم به ذکر است که اگرچه ما تحقیق را به صورت دستی انجام دادیم، اما ابزارهای امنیتی زیادی در دسترس هستند (مثلاً لینس, ببر, هابل) که تجزیه و تحلیل را انجام می دهند و به جلوگیری از پیکربندی های ناامن کمک می کنند. متأسفانه، حتی حفاظت قوی در تنظیمات معقول، عدم وجود اکسپلویت را تضمین نمی کند. به همین دلیل است که ما کاملاً معتقدیم که اطمینان از آن حیاتی است نظارت قابل اعتماد و جلوگیری از حملات در زمان واقعی، تمرکز بر الگوهای استثمار و پیشگیری از آنها.

منبع: www.habr.com