تحلیل فنی آسیب‌پذیری Dirty Frag در هسته لینوکس و ریسک دسترسی روت

باگ امنیتیDirty Pipeبا شناسهCVE-2022-0847یکی از اون LPEهای کلاسیک و دردسرساز کرنل لینوکسه که اگر روی سیستم‌های وصله‌نشده بشینه، یک کاربر لوکال معمولی می‌تونه خیلی تمیز خودش رو تاrootبالا بکشه. تو بعضی منابع فارسی به اشتباه بهش می‌گن «Dirty Frag» یا «روز صفر لینوکس»؛ اسم درستش همونDirty Pipeـه و از نظر تایم‌لاین هم «زیرو دی» به معنای رایجش نبود چون وصله تقریباً هم‌زمان با افشا اومد.

امتیازشCVSS 7.8 (High)ثبت شده و نکته خطرناک اینه که می‌تونه روی فایل‌هایread-onlyمثل `/etc/passwd` هم دست ببره. با اینکه PoC زیاد براش هست و اجرای اکسپلویت هم معمولاً deterministic در میاد، ولی از ۲۰۲۵ تا ۲۰۲۶ گزارش «کمپین گسترده» جدی از سوءاستفاده اینترنتی‌اش نداشتیم. با این حال، تو دیتاسنترهایی که هنوز کرنل‌ها به‌روزرسانی منظم ندارن، همچنان یک ریسک واقعی حساب می‌شه.

تحلیل فنی آسیب‌پذیری

ریشه باگ کجاست؟

Dirty Pipe از نحوه مدیریتpipe bufferداخل کرنل (کدهای مرتبط با Pipe در `pipe.c`) میاد. کرنل برای جابه‌جایی داده بین پردازه‌ها از ساختاری مثل `pipe_buffer` استفاده می‌کنه.

باگ از جایی شروع می‌شه که موقع allocate کردن این ساختار، بعضی فیلدها درستzero-initنمی‌شن. نتیجه؟ فلگ‌های باقی‌مونده از استفاده قبلی توی حافظه می‌مونه؛ مهم‌ترینش هم

`PIPEBUFFLAGCANMERGE`

این فلگ اگر اشتباهی set باشه، کرنل اجازه می‌ده داده جدید «merge» بشه داخل همون buffer—حتی اگر اون buffer به صفحه‌ای ازpage cacheیک فایلread-onlyوصل شده باشه.

سناریوی کلی حمله این شکلیه

1. مهاجم یک Pipe می‌سازه.

2. داده‌ای کنترل‌شده توش می‌نویسه.

3. با `splice()` یا `vmsplice()` صفحه‌های مربوط به یک فایل read-only رو به Pipe وصل می‌کنه (عملاً بازی با page cache).

4. داده دلخواه رو تو Pipe می‌نویسه و کرنل به خاطر اون فلگ اشتباهی، این رو «مجاز» فرض می‌کنه.

5. نتیجه: محتوای فایل read-only تغییر می‌کنه، بدون داشتن permission نوشتن.

از دید عملیاتی، این یعنی bypass شدن مکانیزم مجوزهای فایل در لایه OS و باز شدن مسیر برایprivilege escalationتا سطح root.

نسخه‌های آسیب‌دیده و نسخه‌های امن

نسخه‌های آسیب‌پذیر

Dirty Pipe این بازه‌ها رو تحت تأثیر قرار می‌ده

5.8 تا 5.16.10

شاخه پایدار5.15 تا 5.15.24

شاخه LTS نسخه5.10 تا 5.10.101

توزیع‌هایی مثل Ubuntu 20.04، Debian 11 و RHEL 8 اگر کرنل‌شون تو این بازه بوده، در معرض بوده‌اند.

نسخه‌های وصله‌شده

مشکل در این نسخه‌ها فیکس شده

5.16.11

5.15.25

5.10.102

سری‌های جدید6.x

روش‌های بهره‌برداری

اکسپلویت در عمل چطور کار می‌کند؟

اکسپلویت Dirty Pipe معمولاًقابل اتکااست و روی کرنل‌های آسیب‌پذیر با درصد موفقیت بالا جواب می‌دهد. سناریوی رایج

1. ساخت Pipe توسط کاربر غیرمجاز

2. تزریق داده اولیه داخل Pipe

3. استفاده از `vmsplice()` برای map/attach کردن صفحه فایل هدف (مثلاً `/etc/passwd`) به Pipe

4. نوشتن داده جدید در Pipe و انتقال مستقیم به page cache فایل هدف

5. ساخت مسیر پایدار برای روت

اضافه کردن یک ورودی باUID=0در `/etc/passwd`

یا ایجاد/دستکاری یک باینری با بیتSUID

یک نمونه ساده‌شده از PoCها معمولاً چیزی در این مایه‌هاست (صرفاً برای درک ایده)

c

struct pipebuffer *buf = &pipe->bufs[off / PAGESIZE];

buf->ops = &anonpipebuf_ops;

buf->flags |= PIPEBUFFLAGCANMERGE;

// اتصال به page cache فایل هدف و بازنویسی داده

منابع عمومی

بعد از افشا، منابع زیادی منتشر شد؛ از جمله

وبلاگ رسمیMax Kellermann(کاشف آسیب‌پذیری)

ده‌ها مخزن GitHub شامل PoC و اکسپلویت‌های مختلف

Exploit-DB (EDB-ID: 50807)

ماژول Metasploit برای تست نفوذ

تحلیل‌های فنی در Habr و Seebug

این یعنی اگر یک سرور وصله نشده باشد، «زمان تا اکسپلویت شدن» می‌تونه خیلی کوتاه باشه—خصوصاً داخل شبکه (insider threat / lateral movement).

وضعیت واقعی و آمار (2025–2026)

طبق داده‌های NVD، CISA و اسکن‌های اینترنتی (مثل Shodan)

در ۲۰۲۵ مورد «حمله گسترده» منتسب به Dirty Pipe گزارش نشد.

در ۲۰۲۶ (تا زمان نگارش) نرخ سیستم‌های آسیب‌پذیر متصل به اینترنت کمتر از۰.۱٪برآورد شده.

این CVE در ۲۰۲۴ از لیستKnown Exploited Vulnerabilitiesسازمان CISA خارج شد.

جمع‌بندی: بیرون اینترنت کمتر دیده می‌شه، ولی برای سازمان‌هایی که چرخه patching کند دارند، هنوز یک بردار حمله معتبر برایارتقای دسترسی لوکالاست.

ریسک‌ها و چالش‌ها برای سازمان‌ها

زیرساخت‌های Legacy و کرنل‌های قدیمی

تو خیلی از سازمان‌ها (صنعتی، بانکی، زیرساختی) هنوز با این سناریوها زیاد برخورد می‌کنیم

RHEL/CentOS قدیمی یا کرنل‌های custom

وابستگی نرم‌افزارهای legacy به ورژن‌های مشخص

تغییرات سخت در change management و downtime محدود

تعلل در patch کردن به خاطر «فعلاً کار می‌کنه دست نزن»

اینجا Dirty Pipe خطرناک می‌شه: یک user ساده لوکال، یا یک سرویس compromise شده با دسترسی محدود، می‌تونه برسد به root و عملاً کل ماشین رو بگیرد.

محدودیت‌های دسترسی و تأخیر در وصله

واقعیت محیط ایران اینه که محدودیت روی دسترسی به سرویس‌ها/مخازن خارجی، subscriptionهای تجاری، یا حتی مسیرهای دریافت آپدیت می‌تونه patch window رو کش بده. چند نمونه رایج

عدم دسترسی مستقیم و پایدار به repoهای رسمی

دردسرهای subscription در نسخه‌های enterprise

تأخیر در دریافت و validate کردن آپدیت‌ها

خروجی این شرایط: سیستم وصله‌نشده بیشتر می‌مونه و فرصت سوءاستفاده بالا می‌ره.

روش‌های کاهش ریسک (Mitigation)

اقدامات فوری (Quick Wins)

1. نسخه کرنل را چک کنید

bash

uname -r

2. اگر تو بازه آسیب‌پذیر هستید، سریعاً به نسخه‌های امن ارتقا بدید

5.10.102یا بالاتر

5.15.25یا بالاتر

5.16.11یا سری6.x

3. وصله رسمی توزیع (Vendor Patch) را اعمال کنید، نه patch دستی و غیرقابل ردیابی.

کنترل‌های دفاعی

برای کم کردن blast radius (نه جایگزین patch)

فعال‌سازی و تنظیم درستSELinuxیاAppArmor

لاگ و مانیتورینگ رفتار سیستم با `auditd` و ابزارهایی مثلFalco

رصد الگوهای مشکوک مرتبط با `splice()` / `vmsplice()` (در حد سیاست‌های مانیتورینگ، نه وسواس بی‌فایده)

اجرای اصلLeast Privilegeبرای کاربران و سرویس‌ها

Harden کردن میزبان‌ها و محدود کردن دسترسی shell روی سرورها (خصوصاً سرورهای حساس)

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

توصیه‌های عملیاتی برای تیم‌ها

پایش منظم هشدارهایCERT/NVDو بولتن‌های توزیع‌ها

ساختrepo/mirror داخلیبرای آپدیت‌ها جهت کاهش وابستگی خارجی

اسکن دوره‌ای آسیب‌پذیری‌ها (Vuln Scan) و بستن gapهای patching

تست سناریوهای LPE در محیط آزمایشگاهی (برای اینکه بعداً تو پروداکشن غافلگیر نشید)

جمع‌بندی

Dirty Pipe یک نمونه تمیز از اینه که یک باگ به‌ظاهر «کوچیک» در مدیریت حافظه کرنل می‌تونه به گرفتنrootختم بشه. شاید امروز مثل روزهای اولش داغ نباشه، اما روی سرورهای قدیمی و وصله‌نشده هنوز کاملاً می‌تونه کار کنه. اگر یک چیز قرار باشه از این مقاله ببرید، همینهpatching کرنل رو از کارهای “بعداً” خارج کنید و ببریدش تو روتین عملیاتی.

برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمای پشتیبانی شبکه را نیز مطالعه کنید.