سیستمعامل لینوکس به دلیل نقش کلیدی خود در زیرساخت اینترنت، سرویسهای ابری، ابررایانهها، دستگاههای IoT و بخش بزرگی از دیتاسنترهای سازمانی، همواره یکی از اصلیترین اهداف مهاجمان پیشرفته بوده است. در سالهای ۲۰۲۴ و ۲۰۲۵ با رشد شدید محیطهای کانتینری، معماریهای Cloud-Native، گسترش eBPF و افزایش پیچیدگی هسته، شاهد جهش قابل توجهی در تعداد و شدت آسیبپذیریهای لینوکس در هر دو فضای Kernel-Space و User-Space بودهایم. این مقاله با رویکردی تحلیلی، مهمترین تهدیدات اخیر را بررسی میکند و با تمرکز بر سازوکارهای داخلی هسته، علت بروز این آسیبپذیریها را تبیین مینماید.
وضعیت امنیت و آسیبپذیریهای لینوکس در سالهای اخیر
لینوکس در دو دهه گذشته از یک سیستمعامل تخصصی به زیرساخت اصلی اجرای سرویسهای حیاتی تبدیل شده است. این تنوع کاربرد سبب شده مسیرهای حمله نیز پیچیدهتر شوند. بخش قابل توجهی از تهدیدات امروز ناشی از تعامل میان اجزای متعدد مانند cgroups، namespaceها، سیستمهای فایل مجازی، eBPF، netfilter و ABIهای سازگار با نسخههای قدیمی است. علاوه بر این، نیاز به پشتیبانی طولانیمدت در توزیعهایی مانند RHEL و Ubuntu LTS باعث شده بخش زیادی از کدهای قدیمی Legacy Code همچنان در هسته فعال بمانند و این مسئله احتمال سوءاستفاده را افزایش میدهد.
بررسی آسیبپذیریهای Kernel-Space
بخش kernel طی سالهای اخیر بیشترین سهم را در آسیبپذیریهای بحرانی لینوکس داشته است. یکی از نمونههای مهم، آسیبپذیری معروف CVE-2024-1086 درNetfilter بود که ضعف در مدیریت حافظه و خطای Use-After-Free امکان اجرای کد با سطح دسترسی ریشه را در شرایط خاص فراهم میکرد.netfilter به دلیل پیچیدگی، استفاده گسترده در کانتینریسازی و پردازش شبکه، یکی از نقاط بالقوه خطرناک در معماری هسته محسوب میشود. در این مورد، مهاجم میتوانست با ایجاد شرایط رقابتی یا Race Conditionساختارهایی را که پیشتر آزاد شده بودند دوباره مورد استفاده قرار دهد و موجب دستکاری کنترل جریان برنامه شود.
گسترش حملات در User-Space
اگرچه بخش عمده تمرکز امنیتی روی هسته است، اما آسیبپذیریهای User-Space نیز نقش مهمی در سازوکار حملات مدرن دارند. یکی از حوزههای چالشبرانگیز، کتابخانه glibc است که پایه عملکرد بسیاری از برنامهها محسوب میشود. آسیبپذیریهایHeap Overflow در توابعی مانند qsort یا Iconv در سالهای اخیر امکان اجرای کد در سطح کاربر را تسهیل کرده و بهویژه در شرایطی که مهاجم قبلاً توانسته در یک کانتینر محدود به User Namespace نفوذ کند، این ضعفها بهعنوان نقطه شروع حمله قابل توجه هستند.
علاوه بر این، سرویسهای Daemon حساس مانند polkit،systemd و dbus نیز بارها دچار نقصهای مهم شدهاند. برای مثال، خطای polkit در سالهای پیش امکان ارتقای سطح دسترسی را تنها با اجرای یک دستور ساده فراهم کرد و نسخههای تکاملیافتهتر این تهدیدات همچنان در حال شناسایی هستند. یکی از دلایل اصلی آسیبپذیری در این سطح، افزایش پیچیدگی و سطح انتزاعی این سرویسهاست که اغلب بدون بررسیهای دقیق امنیتی گسترش یافتهاند.
بیشتر بخوانید: تحلیل و بررسی مهمترین آسیبپذیریهای سرویسهای لینوکسی تا نوامبر 2025
اثر معماریهای کانتینری بر گسترش سطح حمله
رشد چشمگیر Docker،Kubernetes و سایر پلتفرمهای Cloud-Native باعث شده بسیاری از حملات جدید از طریق Namespaceها،cgroups و ابزارهای Container Runtime آغاز شوند. برخلاف تصور عمومی، کانتینر یک سازوکار امنیتی کامل نیست، بلکه تنها یک روش ایزولیشن مبتنی بر امکانات خط-به-خط هسته است. کوچکترین نقص در namespaceها یا لایه overlayfs میتواند مهاجم را از داخل یک کانتینر بیخطر به سطح سیستم میزبان برساند.
در سال ۲۰۲۴ آسیبپذیریهای متعددی در overlayfs منتشر شد که به مهاجم داخل کانتینر اجازه میداد با ترکیبی از لینکهای سمبولیک و شرایط رقابتی به فایلهای حساس در سیستم میزبان دسترسی پیدا کند. این حملات اهمیت فعالسازی seccomp، AppArmor،SELinux و محدودیتهای سیستمفایل را بیش از پیش مشخص کرد.
برای مشاوره رایگان جهت (باز)طراحی امنیت شبکه و یا انجام تست نفوذ مطابق با الزامات افتا با کارشناسان شرکت APK تماس بگیرید. |
نقش eBPF در افزایش سطح حمله و ظهور بردارهای جدید
eBPF با توانایی اجرای برنامههای شبهماشینی در حالات مختلف Networking، Observability،Security Monitoring و حتی Filesystem Hooks یکی از مهمترین نقاط تحول امنیت لینوکس است. با وجود اینکه Verifier نقش اساسی در جلوگیری از اجرای کد خطرناک دارد، پیچیدگی بینظیر آن موجب شده خطاهایی کوچک در منطق بررسی مسیرهای اجرای برنامهها، به آسیبپذیریهای شدید منجر شود. در چندین مورد ثابت شده که مهاجم میتواند با ساخت برنامههایی خاص مسیرهایی را طی کند که Verifier قادر به تحلیل کامل آنها نیست و همین موضوع اجازه دسترسی مستقیم به حافظه هسته را فراهم میکند.
افزون بر این، فعال بودن پیشفرض eBPF در بسیاری از توزیعها حتی زمانی که نیازی به آن نیست سطح حمله را گستردهتر میکند. بسیاری ازContainer Runtimeها نیز برای مانیتورینگ از eBPF استفاده میکنند و همین امر موجب میشود یک مهاجم در سطح کانتینر بتواند بخشهایی از زیرسیستم شبکه را که در سطح هسته قرار دارند مورد بررسی یا حتی سوءاستفاده قرار دهد.
بیشتر بخوانید: بررسی راهکارهای تخصصی لینوکس یا Linux Solutions در زیرساختهای مدرن فناوری اطلاعات
تهدیدات ناشی از ABIهای قدیمی و کدهای Legacy
یکی از مشکلات بنیادی لینوکس پشتیبانی بلندمدت از ABIهای قدیمی است. میلیونها برنامه در طول ۲۰ سال گذشته توسعه یافتهاند و ایجاد تغییرات بنیادی در ABI نه ممکن است و نه منطقی. نتیجه این وضعیت انباشت کدهایی است که گاهی برای سازگاری نگهداری میشوند اما عملاً سالهاست استفاده نشدهاند. این بخش از کدها معمولاً کمترین بررسی امنیتی را دریافت میکنند و مهاجمان حرفهای اهمیت ویژهای برای آنها قائل هستند. بسیاری از آسیبپذیریهای جدی سالهای اخیر دقیقاً در چنین مسیرهایی کشف شده است.
حملات مبتنی بر Race Condition و رقابت منابع
افزایش Multithreading پردازشها و پیچیدگی سیستمفایلها و شبکه موجب شده آسیبپذیریهای Race Condition بار دیگر بهعنوان یک مؤلفه اصلی تهدید مطرح شوند. مهاجم میتواند با ایجاد بار سنگین یا ترتیبدهی دقیق عملیات، وضعیتهایی را ایجاد کند که سیستم از نظر منطقی برای آن طراحی نشده است. بسیاری از این حملات allow-list و denial-list را دور میزنند و باعث ایجاد وضعیتهای نادقیق در حافظه میشوند. در مواردی مانند netfilter، io_uring و overlayfs این الگو بارها دیده شده است.
امنیت لینوکس در سالهای ۲۰۲۴ و ۲۰۲۵ بیش از هر زمان دیگری تحت تأثیر پیچیدگی درونی هسته و گسترش فناوریهای وابسته به آن قرار گرفته است. رشد سیستمهای Cloud-Native، eBPF، container runtimeها و نیاز به حفظ سازگاری با کدهای قدیمی، ترکیبی از چالشهای ساختاری ایجاد کرده که مهاجمان خبره به خوبی از آن بهرهبرداری میکنند. گرچه جامعه متنباز با سرعت بالا به اصلاح کدها میپردازد، اما ماهیت توزیعشده، مقیاس عظیم زیرساختها و تنوع نسخهها سبب میشود محیط لینوکسی همچنان یکی از حساسترین عرصهها برای دفاع امنیتی باقی بماند. برای مقابله با این تهدیدات، نیاز به تمرکز بیشتر بر کاهش سطح حمله، غیرفعالسازی قابلیتهای غیرضروری هسته، استفاده از MACها، بررسی مستمر eBPF و بهروزرسانی منظم توزیعها حیاتی است.
نقش eBPF در افزایش سطح حمله و شکلگیری بردارهای پیشرفته نفوذ
ورود eBPF به هسته لینوکس را میتوان نقطهای تعیینکننده در معماری امنیتی این سیستمعامل دانست. این زیرسیستم با هدف فراهمکردن امکان مشاهدهپذیری عمیق، مانیتورینگ پویا، فیلترینگ بستهها، تحلیل عملکرد و Tracing بدون نیاز به توسعه ماژولهای هسته طراحی شده است. اما همین قابلیت اجرای برنامههای کاربری در فضای kernel حتی با وجود سازوکارهای محدودکننده ــ به شکل ناخواسته سطح حمله هسته را گستردهتر کرده است. پیچیدگی بسیار زیاد Verifier، که مسئول بررسی صحت و ایمنبودن برنامههای eBPF است، باعث شده کوچکترین اشتباه منطقی در تحلیل مسیرهای اجرای احتمالی بتواند منجر به نشت حافظه، تجاوز به محدودههای حساس، یا حتی اجرای کد با سطح دسترسی ring0 شود. در چند نمونه از حملات واقعی سال ۲۰۲۴، مهاجمان با سوءاستفاده از نقصهای ظریف در مدیریت pointerها درVerifier، توانستند مسیرهایی را ایجاد کنند که در آنها محدودیتهای حافظه رعایت نمیشد و نهایتاً امکان دستکاری ساختارهای داخلی هسته فراهم میگردید.
این مسئله از آن جهت اهمیت دارد که eBPF در بسیاری از توزیعها بهصورت پیشفرض فعال است و سرویسهایی مانند Kubernetes،Cilium و ابزارهای Observability مدرن بر پایه آن کار میکنند. بنابراین هر آسیبپذیری در زیرسیستم eBPF تنها یک نقص محلی نیست؛ بلکه در محیطهای containerized میتواند به فرار از Container، دسترسی به Nodeهای همجوار و حتی نفوذ به کل کلاستر Kubernetes منجر شود. در پی بررسیهای امنیتی سال ۲۰۲۵، پژوهشگران هشدار دادهاند که برخی ازexploitهای مبتنی بر eBPF به قدری پایدار و مخفیانهاند که میتوانند ماهها بدون شناسایی در سیستم باقی بمانند، چرا که رفتار آنها در سطح هسته انجام میشود و بسیاری از ابزارهای مانیتورینگ سنتی در برابر چنین فعالیتی کور هستند.
ضعفهای ساختاری درNamespaceها و پیامدهای امنیتی در محیطهای Containerized
Namespaces بهعنوان یکی از ستونهای امنیتی در لینوکس، وظیفه جداسازی منابع سیستم را در اجرای فرآیندها بر عهده دارند. با گسترش Docker،LXC و Kubernetes، استفاده ازNamespaceها به شدت افزایش یافته و اکنون تقریباً تمام سرویسهای ابری مبتنی بر Containerها از آن برای ایجاد جداسازی میان سرویسها استفاده میکنند. با وجود این، پروژههای امنیتی طی دو سال اخیر چندین بار نشان دادهاند که Namespaceها ماهیتاً یک سازوکار hard-isolation نیستند و تنها تا حدی جداسازی منطقی ایجاد میکنند. این موضوع بهخصوص زمانی بحرانی میشود که Container دارای قابلیتهایی مانند CAP_SYS_ADMIN یا دسترسی به برخی pseudofsها باشد که میتواند مهاجم را قادر سازد از محدودیتهای Namespace خارج شود.
یکی از آسیبپذیریهای جدی کشفشده در سال ۲۰۲۴ نشان داد که تعامل پیچیده میان mount namespace و user namespace میتواند امکان دستکاری فایلهای حساس سیستمعامل میزبان را فراهم کند. این نقص باعث شد مهاجمان در محیطهایی که Container بهطور نادرست پیکربندی شده بودند، با تغییر مسیر Mountهای درونی، به Mountهای سطح میزبان دست پیدا کنند و این دقیقاً نقطهای بود که برخی سازمانها را مجبور کرد بهروزرسانیهای فوری امنیتی منتشر کنند. مشکل اساسی این است که پیادهسازی Namespaceها در هسته، اگرچه بالغ و پایدار به نظر میرسد، اما هنوز شامل مسیرهای کد قدیمی و تعاملات غیرمستندی است که سطح حملهای پیچیده و چندبعدی را شکل میدهند.
تهدیدات جدی مربوط به قابلیتهای هسته یا Linux Capabilities
قابلیتها در لینوکس با هدف جایگزینی مدل قدیمی All-or-Nothing مربوط به دسترسی Root طراحی شدند. بر اساس این مدل، دسترسی Root به دهها قابلیت کوچکتر تقسیم شده است که هر کدام مسئول انجام یک وظیفه مشخص هستند. با این حال، تجربه عملی در سالهای اخیر نشان داده که برخی از این قابلیتها بهشدت پرخطر هستند و اعطای تنها یک قابلیت اشتباه میتواند معادل اعطای دسترسی کامل Root باشد.
یکی از مشکلسازترین قابلیتها، CAP_SYS_ADMIN است که تقریباً در همه پژوهشهای امنیتی به God Capability معروف است. این قابلیت به اندازهای گسترده تعریف شده که مهاجم با در اختیار داشتن آن در بسیاری از سناریوها میتواند از محدودیتهای Container خارج شده، تنظیمات امنیتی را غیرفعال کند، به فضای نامهای دیگر وارد شود یا کد دلخواه در سطح هسته اجرا کند. در چند رخداد امنیتی مهم سال ۲۰۲۵ مشخص شد برخی اپلیکیشنهای سازمانی بدون ارزیابی امنیتی،CAP_NET_ADMIN یا CAP_SYS_PTRACE را به Containerها اعطا کردهاند و همین امر دسترسی مهاجم را به سطحی رسانده که امکان تزریق ترافیک،Sniffing داخلی، تغییر Routing و حتی تزریق کد به فرآیندهای کلیدی سیستم فراهم میشد. این نقاط ضعف ریشه در طراحی اولیه قابلیتها دارد که به دلیل نیاز به Backward Compatibility، اصطلاحاً «چاق» شده و پوشش عملکردی بسیار بیشتری از آنچه نیاز است در اختیار فرآیند قرار میدهد.
هسته لینوکس بهعنوان هدف اصلی حملات Persistent وRootkitهای نسل جدید
یکی از روندهای نگرانکننده در سالهای ۲۰۲۴ و ۲۰۲۵ افزایش چشمگیر Rootkitهایی است که بهجای استتار درUser-Space، مستقیماً به ساختارهای داخلی kernel حمله میکنند. تکامل ابزارهای observability و تشخیص حمله باعث شده مهاجمان برای ناشناسماندن به سمت لایههای پایینتر بروند. در این گروه از حملات، تکنیکهایی مانندHook کردن sys_call_table، دستکاری ساختارهای kernel slab، در LSMهای فعال و تغییر مسیرهای بازگشت در توابع پرکاربرد، رایج شده است.
تحقیقات اخیر نشان میدهد بسیاری از Rootkitهای جدید از آسیبپذیریهای حافظه مانند Use-After-Free یا Race Condition استفاده میکنند تا ابتدا یک primitive برای نوشتن در حافظه هسته به دست آورند و سپس با بارگذاری خود در مسیرهای عادی اجرا، حضورشان را بهطور کامل مخفی کنند. نکته مهم این است که بسیاری از این Rootkitها در حالت liveless اجرا میشوند، یعنی بدون نیاز به Drop فایل در دیسک. این ویژگی باعث میشود حتی سامانههای EDR سازمانی که برای لینوکس طراحی شدهاند نیز در شناسایی آنها با دشواری مواجه شوند.
این دسته از بدافزارها معمولاً از طریق سرویسهایی وارد سیستم میشوند که با سطح دسترسی بالا اجرا میشوند یا از طریق Containerهایی که دارای قابلیتهای خطرناک هستند. همین روند موجب شده سازمانها به سمت استفاده از هستههای Hardened و LSMهای چندلایه مانند SELinux، AppArmor و Landlock حرکت کنند، هرچند بسیاری از این راهکارها هنوز در برابر حملات مبتنی بر eBPF مقاومت کامل ندارند.
