آسیبپذیری CVE-2024-21626 که در ژانویه 2024 توسط تیم امنیتی Snyk کشف و گزارش شد، یکی از جدیترین آسیبپذیریهای مرتبط با زیرساخت کانتینری Docker در سالهای اخیر محسوب میشود. این آسیبپذیری، مهاجم را قادر میسازد تا از یک کانتینر محدودشده فرار کرده و کد دلخواه خود را در سطح میزبان اجرا کند. در این مقاله، تحلیل فنی دقیق، شرایط بهرهبرداری، پیامدهای امنیتی و راهکارهای مقابله با این آسیبپذیری ارائه میشود.
چرا آسیبپذیری CVE-2024-21626 اهمیت دارد؟
کانتینرها به عنوان واحدهای سبکوزن مجازیسازی، از هسته سیستمعامل میزبان بهصورت مشترک استفاده میکنند. لذا هرگونه آسیبپذیری که امکان اجرای کد از درون کانتینر به خارج (host escape) را فراهم کند، تهدیدی بسیار جدی برای امنیت زیرساخت محسوب میشود. آسیبپذیری CVE-2024-21626 از همین نوع است و از نقصی در مدیریت TTY توسط runc بهرهبرداری میکند.
معرفی آسیبپذیری CVE-2024-21626
- شناسه: CVE-2024-21626
- مولفه آسیبپذیر: runc کامپوننت اجرای کانتینر در Docker و Podman
- نوع آسیبپذیری: TTY escape و privilege escalation
- شدت (CVSS): 8.6 از 10
- حالت بهرهبرداری: نیازمند دسترسی به اجرای یک کانتینر با TTY فعال و اجرای باینری Setuid مانند Su
نحوه عملکرد آسیبپذیری: تحلیل فنی
این آسیبپذیری از یک باگ در نحوه مدیریت psuedoterminal (PTY) توسط runc ناشی میشود. زمانیکه کاربر داخل کانتینر یک باینری Setuid مثل su را با TTY فعال اجرا میکند، خطای منطقی در مدیریت ترمینال میتواند باعث شود stdin/stderr بهاشتباه به کانتکست خارج از کانتینر اشاره کنند. این شرایط زمینهای برای اجرای کد خارج از محیط sandbox فراهم میکند.
- اجرای یک کانتینر با TTY فعال:
docker run -it –rm vulnerable-image
- اجرای یک باینری setuid داخل کانتینر مثلا su
su
- سوءاستفاده از رفتار اشتباه در مدیریت File Descriptorها برای نوشتن خارج از کانتینر
محققان Snyk اثبات کردند که با بهرهگیری از این خطا میتوان فایلهای سیستمی روی میزبان را از درون کانتینر بازنویسی کرد یا فرآیندهای خارج از کانتینر را تحت تأثیر قرار داد.
شرایط بهرهبرداری Exploitation Requirements
برای بهرهبرداری موفق از این آسیبپذیری، شرایط زیر باید برقرار باشد:
- کانتینر با TTY فعال اجرا شود -it یا –tty
- باینری دارای Setuid داخل کانتینر قابل اجرا باشد
- نسخه آسیبپذیر از Runc مورد استفاده باشد قبل از v1.1.12
- سیستم میزبان فاقد مکانیسمهای ایزولهسازی سختگیرانه مثل SELinux یا AppArmor فعال باشد
دامنه تأثیر و ریسک سازمانی
با توجه به گستردگی استفاده از Docker و Podman در محیطهای DevOps، CI/CD و زیرساختهای ابری، بهرهبرداری موفق از این آسیبپذیری میتواند به نتایج زیر منجر شود:
- اجرای کد دلخواه در سطح Root روی میزبان
- دسترسی به secrets، فایلهای لاگ و سایر کانتینرها
- pivot کردن مهاجم به زیرساخت شبکه سازمان
- تخریب یا تغییر دادههای حیاتی
بیشتر بخوانید: روش هایی که برای تقویت امنیت Docker مهم هستند
بررسی نسخهها و وضعیت patch
runc نسخههای زیر تحت تأثیر قرار دارند:
- v1.1.11 و پایینتر
- تمام نسخههای Docker Engine که از این نسخهها استفاده میکنند
Patch امنیتی در نسخه v1.1.12 منتشر شده و توسط توزیعهایی مانند Ubuntu، Red Hat و Alpine نیز وارد شده است. تیم Docker نیز در نسخه Docker Engine 24.0.7 این patch را لحاظ کرده است.
برای مشاوره رایگان و یا پیاده سازی راهکارهای پشتیبان گیری و ذخیره سازی با کارشناسان شرکت APK تماس بگیرید. |
راهکارهای مقابله و کاهش ریسک Mitigation
- بهروزرسانی :runc اطمینان حاصل کنید که نسخه نصبشده حداقل v1.1.12 باشد:
runc –version
- اجتناب از اجرای کانتینر با TTY در محیطهای حساس
- غیرفعالسازی اجرای باینریهای Setuid در داخل کانتینر
- استفاده از AppArmor/SELinux برای محدود کردن دسترسی کانتینرها
- فعالسازی seccomp profile محدودکننده برای کانتینرها
تشخیص و تحلیل رفتار مخرب Detection & Forensics
- بررسی لاگهای Auditd برای فعالیتهای غیرمعمول داخل کانتینر
- استفاده از ابزارهایی مانند Falco یا Sysdig برای رصد فعالیتهای فایل سیستم خارج از کانتینر
- بررسی لیست Processهای میزبان که Parent آنها کانتینر نیست ولی رفتار مشابه دارند
توصیههای سازمانی و سیاستگذاری امنیتی
- ممنوعیت اجرای کانتینر با TTY بهصورت پیشفرض در پلتفرمهای orchestrator مانند Kubernetes
- پیادهسازی ابزارهای Runtime Security برای Container Monitoring
- انجام تستهای نفوذ دورهای در محیطهای کانتینری با تمرکز بر Escape Scenarios
آسیبپذیری CVE-2024-21626 یادآور آن است که کانتینرها Sandbox امنیتی کامل نیستند و اشتباه در پیادهسازی حتی یک ماژول کوچک مانند TTY management میتواند منجر به فرار کامل از کانتینر شود. سازمانها باید بهصورت مداوم زیرساخت کانتینری خود را پچ کنند، از اجرای غیرضروری باینریهای دارای privilege اجتناب کنند و سیاستهای سختگیرانهتری در مدیریت کانتینرها اتخاذ نمایند. بهروزرسانی مداوم، پایش هوشمند و پیادهسازی کنترلهای چندلایه، ستون فقرات امنیت در محیطهای مبتنی بر container خواهد بود.
بیشتر بخوانید: شباهتهای بین مجازیسازی و کانتینرهای Kubernetes
چکلیست امنیتی مقابله با آسیبپذیری CVE-2024-21626
شناسایی وضعیت فعلی Assessment
| مورد | توضیح | وضعیت |
|---|---|---|
بررسی نسخه فعلی runc | اجرای دستور runc --version و بررسی اینکه نسخه ≥ v1.1.12 باشد | ☐ |
| شناسایی کانتینرهایی که با TTY اجرا میشوند | جستجو در فایلهای YAML (Kubernetes) یا دستورهای اجرا شده | ☐ |
بررسی وجود باینریهای setuid در کانتینرها | استفاده از find / -perm -4000 در داخل کانتینر | ☐ |
| بررسی policyهای AppArmor/SELinux فعال بر روی کانتینرها | برای اطمینان از محدودیت کافی | ☐ |
مهار فوری آسیبپذیری Containment
| مورد | توضیح | وضعیت |
|---|---|---|
حذف یا بهروزرسانی کانتینرهای دارای TTY فعال و نسخه آسیبپذیر runc | توقف و حذف کانتینرهایی که در معرض خطر هستند | ☐ |
| غیرفعالسازی قابلیت اجرای باینریهای setuid داخل image | اصلاح Dockerfile و بازسازی image | ☐ |
بلاک کردن قابلیت اجرای کانتینرهای جدید با --tty در محیطهای production | با استفاده از Admission Controller در Kubernetes یا Policy Enforcement | ☐ |
اصلاح زیرساخت و نصب پچ Remediation
| مورد | توضیح | وضعیت |
|---|---|---|
بهروزرسانی runc به نسخه ≥ 1.1.12 | استفاده از package manager یا نصب دستی از سورس | ☐ |
| ارتقای Docker Engine به نسخه ≥ 24.0.7 | بررسی از طریق docker version و استفاده از نصب رسمی | ☐ |
| بهروزرسانی توزیع پایه (Base Image) کانتینرها | بهویژه در تصاویر Alpine، Ubuntu، Debian | ☐ |
| بازسازی تصاویر کانتینر با پایه امن | اطمینان از عدم وجود باینریهای setuid | ☐ |
پایش و تشخیص بهرهبرداری Detection
| مورد | توضیح | وضعیت |
|---|---|---|
| فعالسازی auditd در میزبان | برای مانیتور تغییرات فایل و اجرای باینریهای غیرمنتظره | ☐ |
| استفاده از ابزارهایی مانند Falco یا Sysdig | تشخیص فعالیتهای نوشتن فایل خارج از کانتینر یا تغییر Process Tree | ☐ |
پایش فایلهای حساسی مانند /etc/shadow، /etc/passwd | برای بررسی تغییرات غیرمجاز از داخل کانتینر | ☐ |
| ثبت هش imageهای رسمی و مقایسه با نسخه در حال اجرا | برای تشخیص tampering یا drift | ☐ |
تقویت سیاستهای امنیتی Hardening
| مورد | توضیح | وضعیت |
|---|---|---|
| اعمال Seccomp profile محدودکننده | جلوگیری از syscallهای خطرناک مانند ptrace, setns, mount | ☐ |
| استفاده از AppArmor یا SELinux profile ویژه کانتینرها | محدودسازی دسترسی به host filesystem و فرآیندها | ☐ |
جلوگیری از دسترسی کانتینر به /proc یا /sys | با استفاده از تنظیمات امنیتی در Kubernetes یا Docker | ☐ |
| ممنوعیت اجرای privileged containers | مگر در موارد خاص و کنترلشده | ☐ |
اقدامات سازمانی و سیاستگذاری
| مورد | توضیح | وضعیت |
|---|---|---|
| آموزش تیم DevOps در مورد escape risks | اطلاعرسانی از سناریوهای فرار از کانتینر و سیاستهای پیشگیری | ☐ |
| تدوین Policy اجرای کانتینرها بدون TTY و setuid | ثبت در CI/CD pipeline یا Kubernetes admission control | ☐ |
| اجرای اسکن امنیتی imageها پیش از استقرار | با ابزارهایی مانند Trivy، Clair، Grype | ☐ |
| بازبینی دورهای سطح دسترسی کانتینرها به شبکه داخلی | برای کاهش حرکت جانبی پس از Escape | ☐ |
چکنهایی اقدامات ضروری
✅ بهروزرسانی فوری runc و Docker
✅ غیرفعالسازی TTY و حذف باینریهای setuid
✅ اجرای Seccomp و AppArmor برای همه کانتینرها
✅ نظارت Real-Timeبر رفتار کانتینر با Falco یا معادل آن
✅ سیاست امنیتی روشن برای جلوگیری از Privilege Escalation
