تشریح آسیب‌پذیری Dirty Frag لینوکس با امکان دسترسی روت؛ آموزش تشخیص و ایمن‌سازی

آسیب‌پذیری Dirty Frag لینوکس که به تازگی تشخیص داده شده و توسط برخی هکرها از آن سوء استفاده شده، می‌تواند مشکلات امنیتی جدی از جمله دسترسی روت را به همراه داشته باشد. در این مطلب به جزئیات این آسیب‌پذیری، روش سوء استفاده احتمالی هکرها از آن و روش‌های تشخیص و ایمن‌سازی در مقابل باگ Dirty Frag می‌پردازیم.

نقص امنیتی Dirty Frag چیست و چگونه عمل می‌‌کند؟

نقص امنیتی Dirty Frag می‌تواند به یک کاربر با سطح دسترسی پایین، با استفاده از نقص‌های ماژول کرنل esp6 ،esp4 و rxrpc سطح دسترسی روت بدهد و در ادامه این کاربر می‌تواند دستوراتی با سطح دسترسی روت را اجرا کند. کد اثبات مفهوم این آسیب‌پذیری منتشر شده و به همین دلیل حالا یک ریسک فوری محسوب می‌شود.

در جدول زیر کلیات مربوط به باگ Dirty Frag ذکر شده است:

Dirty Frag در مقایسه با بسیاری از دیگر آسیب‌پذیری‌های ارتقای سطح دسترسی محلی (LPE)، پتانسیل بسیار بیشتری برای سوء استفاده دارد. این نقص امنیتی به‌صورت زنجیره‌ای، از لایه‌های پردازش شبکه و قطعه‌های حافظه در کرنل سوءاستفاده می‌کند و بر خلاف بسیاری از نقص‌های دیگر، با تکیه بر شرایط رقابتی (Race Condition) عمل نمی‌کند. در روش‌های مبتنی بر شرایط رقابتی، مهاجم سعی می‌کند با دستکاری زمان‌بندی بین عملیات‌ها، برنامه را وادار به انجام کاری کند که برنامه‌نویس انتظارش را نداشته است و به دلیل وابستگی این شرایط به زمان‌بندی، می‌تواند غیر قابل اعتماد باشد. روش باگ Dirty Frag موجب می‌شود این حمله پایدار، قابل‌اتکا و به‌سادگی قابل بازتولید باشد. در نتیجه مهاجم پس از به‌دست آوردن نخستین دسترسی خود به محیط هدف، می‌تواند این آسیب‌پذیری را به‌آسانی مورد سوءاستفاده قرار دهد.

چه توزیع‌هایی در معرض این آسیب‌پذیری هستند؟

تمام توزیع‌های اصلی از جمله موارد زیر در معرض این آسیب‌پذیری هستند:

• Ubuntu
• Rocky Linux
• AlmaLinux
• CentOS Stream
• RHEL (یا Red Hat Enterprise Linux)
• Fedora
• openSUSE
• OpenShift

تحلیل فنی آسیب‌پذیری‌های تشکیل‌دهنده نقص امنیتی Dirty Frag

باگ Dirty Frag از دو آسیب‌پذیری متفاوت در کرنل لینوکس تشکیل شده است که کامپوننت شبکه و کامپوننت مدیریت قطعه‌های حافظه را تحت تأثیر قرار می‌دهند.

نخستین آسیب‌پذیری با شناسه CVE-2026-43284، مؤلفه‌های esp4 و esp6 را هدف قرار می‌دهد. این مؤلفه‌ها مسئول پردازش ESP ‏(مخفف Encapsulated Security Payload) هستند که یکی از پروتکل‌های اصلی در فریم‌ورک IPsec محسوب می‌شود. دومین آسیب‌پذیری با شناسه CVE-2026-43500، کامپوننت rxrpc را تحت تأثیر قرار می‌دهد؛ پروتکلی که در فایل‌سیستم توزیع‌شده AFS مورد استفاده قرار می‌گیرد.

مهاجمی که از قبل از طریق دسترسی SSH، وب‌شل، فرار از کانتینر یا حتی یک حساب کاربری با سطح دسترسی پایین به سیستم نفوذ کرده باشد، می‌تواند از این زنجیره برای دستیابی به دسترسی کامل روت روی میزبان استفاده کند.

آیا سیستم‌عامل سرور من تحت تاثیر باگ Dirty Frag قرار گرفته است؟

برای بررسی کرنل فعلی سیستم‌عامل خود دستور زیر را اجرا کنید:

uname -r

uname -r

همین حالا می‌توانید با اجرای یک ماژول مسدودسازی در سطح کرنل یک راهکار موقت را اعمال کنید. اما توجه داشته باشید که غیر فعال کردن esp4 و esp6 ممکن است اتصال‌های VPN مبتنی بر IPsec را با مشکل مواجه کند. به همین دلیل پیشنهاد می‌کنیم پیش از اجرای فرایند مسدودسازی، راهنما را به دقت مطالعه کنید.

همه نسخه‌های کرنل در همه توزیع‌های فهرست‌شده، تا زمانی که یک بسته کرنل وصله‌شده نصب نشود، آسیب‌پذیر در نظر گرفته می‌شوند. همچنین می‌توانید بررسی کنید که آیا ماژول‌های آسیب‌پذیر در حال حاضر روی سیستم‌عامل شما بارگذاری شده‌اند یا خیر. توجه داشته باشید که برخی توزیع‌ها این ماژول‌ها را با نام‌های متفاوتی مانند xfrm4_tunnel یا xfrm6_tunnel کامپایل می‌کنند؛ بنابراین بهتر است از یک grep گسترده‌تر استفاده شود:

lsmod | grep -E 'esp|xfrm|rxrpc'

lsmod | grep -E 'esp|xfrm|rxrpc'

در صورتی‌که این دستور هرگونه خروجی شامل esp6 ،esp4 یا rxrpc برگرداند، به این معناست که این ماژول‌ها بارگذاری شده‌اند و سیستم‌عامل شما تا زمان اعمال راهکار کاهش خطر (Mitigation) یا به‌روزرسانی کرنل، قابل سوء استفاده خواهد بود. نام دقیق ماژول‌های نمایش‌داده‌شده را یادداشت کنید، زیرا در مراحل بعدی به آن‌ها نیاز خواهید داشت.

روش ایمن‌سازی در مقابل نقص امنیتی Dirty Frag

این راهکار موقت، از طریق جلوگیری از بارگذاری سه ماژول کرنل عمل می‌کند. در حال حاضر اعمال این راهکار ایمن است؛ حتی پیش از آنکه وصله کرنل برای توزیع شما منتشر شود.

ایمن‌سازی اوبونتو (نسخه فعلی و تمام توزیع‌های LTS)

آسیب‌پذیری، برای توزیع 26.04LTS و تمام توزیع‌های قدیمی‌تر (از 14.04 به بعد) تایید شده است.

قدم اول: تایید نام ماژول دقیق در کرنل سیستم‌عامل شما

توزیع‌ها گاهی esp4/esp6 را با نام‌های متفاوتی مثل xfrm4_tunnel و xfrm6_tunnel کامپایل می‌کنند. قبل از نوشتن فایل پیکربندی، بررسی کنید کرنل دقیقاً از چه نام‌هایی استفاده می‌کند:

lsmod | grep -E 'esp|xfrm|rxrpc'

lsmod | grep -E 'esp|xfrm|rxrpc'

در تمام دستورات بعدی باید دقیقاً از همان نام‌هایی استفاده کنید که در خروجی می‌بینید.

قدم دوم: مسدودسازی ماژول‌ها و قرار دادن در لیست سیاه

خط install ... /bin/false مانع بارگذاری ماژول از طریق modprobe می‌شود. خط blacklist نیز مثلاً هنگامی‌که یک نوع بسته شبکه خاص دریافت می‌شود، جلوی بارگذاری خودکار ماژول توسط کرنل از طریق alias دستگاه را می‌گیرد. برای پوشش کامل، هر دو لازم هستند:

sudo echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp4" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp6" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist rxrpc" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

sudo echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp4" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp6" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist rxrpc" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

قدم سوم: ریبیلد initramfs (مرحله هاردنینگ عمیق)

این کار تضمین می‌کند که ماژول‌ها حتی در مراحل ابتدایی بوت و قبل از mount شدن فایل‌سیستم روت، در دسترس نباشند. در بیشتر سیستم‌ها esp6 ،esp4 و rxrpc بعد از بوت لود می‌شوند، بنابراین اگر برای اجرای مراحل بعدی، عجله دارید، این مرحله اختیاری است، اما همچنان یک اقدام توصیه شده است:

sudo update-initramfs -u -k all

sudo update-initramfs -u -k all

قدم چهارم: unload کردن ماژول‌ها (در صورتی که در حال اجرا هستند)

به‌جای rmmod از modprobe -r استفاده کنید. این موضوع موجب می‌شود که ماژول‌ها به ترتیب صحیح unload شوند و در نتیجه خطای «module is in use» که در rmmod رخ می‌دهد پیش نیاید:

sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

قدم پنجم: بررسی صحت اجرای راهکار

در این مرحله دستور زیر را اجرا کنید:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Still loaded - reboot needed" || echo "Modules removed successfully"

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Still loaded - reboot needed" || echo "Modules removed successfully"

ایمن‌سازی Rocky Linux ،AlmaLinux و CentOS Stream

فرایند اعمال راهکار کاهش خطر در سیستم‌های مبتنی بر RHEL از جمله Rocky Linux مسیر کمی متفاوتی دارد؛ زیرا ابزار initramfs در این خانواده متفاوت است.

قدم اول: تایید نام دقیق ماژول‌ها روی کرنل

برخی کرنل‌های خانواده RHEL نام‌های متفاوتی را برای ماژول‌های ESP کامپایل می‌کنند. قبل از نوشتن فایل پیکربندی، آن را بررسی کنید:

lsmod | grep -E 'esp|xfrm|rxrpc'

lsmod | grep -E 'esp|xfrm|rxrpc'

قدم دوم: مسدودسازی ماژول‌ها و قرار دادن در لیست سیاه

هر دو دستور install (برای جلوگیری از بارگذاری توسط modprobe) و blacklist (برای جلوگیری از بارگذاری خودکار مبتنی بر alias) باید در یک فایل قرار داده شوند:

sudo echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp4" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp6" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist rxrpc" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

sudo echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp4" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist esp6" | sudo tee -a /etc/modprobe.d/dirty-frag.conf<br>
sudo echo "blacklist rxrpc" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

قدم سوم: بازسازی initramfs با dracut (مرحله هاردنینگ عمیق)

در بیشتر سیستم‌ها این ماژول‌ها پس از بوت بارگذاری می‌شوند، بنابراین اگر برای اجرای مراحل بعدی، عجله دارید، این مرحله اختیاری است، اما همچنان یک اقدام توصیه شده است:

sudo dracut -f --regenerate-all

sudo dracut -f --regenerate-all

قدم چهارم: unload کردن ماژول‌ها (در صورتی که در حال اجرا هستند)

از modprobe -r استفاده کنید تا زنجیره وابستگی‌ها را به‌درستی مدیریت کند:

sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

قدم پنجم: بررسی صحت اجرای راهکار

در این مرحله دستور زیر را اجرا کنید:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Still loaded - reboot needed" || echo "Modules removed successfully"

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Still loaded - reboot needed" || echo "Modules removed successfully"

باگ Dirty Frag چه تاثیری بر کانتینرها و محیط‌های ابری دارد؟

اگر از Docker ،Podman یا OpenShift برای اجرای workloadها استفاده می‌کنید، وضعیت ریسک پیچیده‌تر از یک عبارت ساده مثل «ریسک بالاتر» است. جزئیات آن به این شکل است:

روی یک کانتینر Docker استاندارد که هاردنینگ آن به درستی انجام شده و هیچ قابلیت ارتقایافته‌ای (elevated capabilities) ندارد، باگ Dirty Frag باعث می‌شود مهاجم به سطح روت داخل Namespace شبکه کانتینر دست پیدا کند. این وضعیت بد است، اما مهاجم همچنان داخل همان محیط ایزوله باقی می‌ماند و به‌صورت خودکار به سیستم میزبان دسترسی پیدا نمی‌کند.

خطر واقعی زمانی ایجاد می‌شود که کانتینرها به‌صورت privileged (با فلگ --privileged) اجرا شوند یا دارای قابلیت‌هایی مثل CAP_SYS_ADMIN ،CAP_NET_ADMIN باشند، یا از فضای نام شبکه میزبان (--net=host) استفاده کنند. در چنین محیط‌هایی، ارتقا به روت داخل کانتینر می‌تواند مستقیماً به روت روی سیستم میزبان تبدیل شود. این همان سناریوی واقعی «خروج از کانتینر» (container escape) است و در تعداد زیادی از workloadهای واقعی، از جمله بسیاری از رانرهای CI/CD و sidecarهای service mesh، دیده می‌شود.

در همه موارد باید راهکارهای ایمن‌سازی مربوط به ماژول‌های کرنل را روی میزبان اعمال کنید. همچنین کانتینرهای در حال اجرای خود را برای وجود فلگ‌های --privileged و --net=host بررسی و ممیزی کنید:

docker ps -q | xargs docker inspect --format '{{.Name}} Privileged={{.HostConfig.Privileged}} NetworkMode={{.HostConfig.NetworkMode}}'

docker ps -q | xargs docker inspect --format '{{.Name}} Privileged={{.HostConfig.Privileged}} NetworkMode={{.HostConfig.NetworkMode}}'

آیا SELinux یا AppArmor کمک می‌کنند؟

هر دو مکانیزم SELinux (به‌صورت پیش‌فرض در RHEL،Rocky و AlmaLinux) و AppArmor (به‌صورت پیش‌فرض در Ubuntu) لایه‌های کنترل دسترسی اضافه‌ای فراهم می‌کنند که می‌توانند پس از وقوع یک exploit، محدوده کاری آن را محدود کنند. با این حال، هیچ‌کدام به‌طور کامل جلوی خودِ ارتقای سطح دسترسی در نقص امنیتی Dirty Frag را نمی‌گیرند. اگر یک کاربر بتواند ماژول‌های آسیب‌پذیر را بارگذاری کند یا با آن‌ها تعامل داشته باشد، حمله LPE همچنان قابل اجرا خواهد بود. بنابراین راهکار اصلی، همان بلاک کردن ماژول‌های کرنل است که در بالا توضیح داده شد.

با این وجود، بهتر است SELinux در حالت enforcing و AppArmor در همه سیستم‌ها فعال باقی بمانند. این ابزارها دفاع لایه‌به‌لایه (defense-in-depth) ایجاد می‌کنند و در صورت وقوع هر exploit دیگر در کنار این آسیب‌پذیری، میزان خسارت را کاهش می‌دهند. انتظار می‌رود کرنل لینوکس 7.0 شامل بهبودهای هاردنینگ باشد که ممکن است سطح حمله این نوع آسیب‌پذیری‌ها را کاهش دهد.

عیب‌یابی: اگر اعمال راهکار باعث مشکل شد چه باید کرد؟

همان‌طور که پیش از این اشاره کردیم، اعمال این راهکار ممکن است باعث بروز مشکلاتی شود. در ادامه به این مشکلات و راهکارهای رفع آن اشاره می‌کنیم

از کار افتاددن IPsec / VPN بعد از بلاک کردن esp4 و esp6

این موضوع در صورتی که از VPN مبتنی بر IPsec استفاده می‌کنید، کاملاً قابل انتظار است. ماژول‌های esp4 و esp6 ترافیک ESP را مدیریت می‌کنند. غیرفعال کردن آن‌ها باعث از کار افتادن هر تونلی می‌شود که از IPsec استفاده می‌کند. در این حالت دو انتخاب دارید: یا downtime را بپذیرید و منتظر انتشار کرنل وصله‌شده بمانید، یا بررسی کنید که آیا می‌توان VPN را به‌صورت موقت روی یک پروتکل غیر IPsec مثل WireGuard تغییر داد تا زمان رفع مشکل برسد.

مشکل در حال استفاده بودن و unload نشدن ماژول از طریق modprobe -r

این حالت زمانی رخ می‌دهد که یک فرایند فعال در حال استفاده از ماژول باشد. فایل /etc/modprobe.d/dirty-frag.conf (که شامل هر دو دستور install و blacklist است) به همراه بازسازی initramfs باعث می‌شود ماژول‌ها در بوت بعدی بارگذاری نشوند. برای اعمال فوری این محدودیت می‌توانید سیستم را ریبوت کنید:

sudo reboot

sudo reboot

چگونه بعد از نصب وصله، راهکار اعمال شده را حذف کنیم؟

پس از اینکه توزیع شما یک کرنل وصله‌شده ارائه داد و آن را نصب کردید، فایل بلاک را حذف کنید:

sudo rm /etc/modprobe.d/dirty-frag.conf

sudo rm /etc/modprobe.d/dirty-frag.conf

سپس initramfs را دوباره بسازید.
(در اوبنوتو: sudo update-initramfs -u -k all و در راکی‌لینوکس: sudo dracut -f --regenerate-all) و سیستم را ریبوت کنید.

در نهایت با دستور زیر بررسی کنید که کرنل وصله‌شده در حال اجرا است:

uname -r

uname -r