CopyEscape: باگ docker cp به کانتینرهای مخرب اجازهٔ بازنویسی فایل‌های میزبان را می‌داد

تیم قرمز Imperva در ۱۰ اوت ۲۰۲۶ آسیب‌پذیری «CopyEscape» با شناسهٔ CVE-2026-17106 را افشا کرد؛ باگی که به یک کانتینر مخرب اجازه می‌دهد از طریق دستور به‌ظاهر بی‌خطر docker cp فایل‌های دلخواه روی میزبان را بازنویسی کند و در سناریوی نهایی، به اجرای کد با سطح root برسد.

#چه اتفاقی افتاد؟

پژوهشگران Imperva Red Team نشان دادند که زنجیره‌سازی یک شرط مسابقه‌ای TOCTOU در ساخت آرشیو tar با دنبال‌کردن symlink در هنگام استخراج، به محتوای تحت کنترل مهاجم درون کانتینر اجازه می‌دهد هنگام اجرای docker cp (و sbx cp در سندباکس‌های داکر) از محدودهٔ کانتینر فرار کند و روی سیستم‌فایل میزبان بنویسد. در شدیدترین سناریو، بازنویسی باینری /usr/bin/runc به اجرای کد با دسترسی root روی میزبان منجر می‌شود. کد اثبات مفهومی (PoC) این حمله به‌صورت عمومی موجود است و بازتولید اکسپلویت و پوشش خبری آن تا ۱۸ اوت ادامه یافت.

نسخه‌های وصله‌شده عبارت‌اند از: Docker Engine و CLI نسخهٔ 29.7.2، Docker Desktop نسخهٔ 4.86.0 و Sandboxes نسخهٔ 0.38.0.

#جزئیات فنی

مکانیزم حمله ترکیب دو ضعف کلاسیک است:

1. TOCTOU (Time-of-Check to Time-of-Use): میان لحظهٔ بررسی محتوای کانتینر برای ساخت آرشیو و لحظهٔ استفادهٔ واقعی از آن، فاصلهٔ زمانی وجود دارد. کانتینر مخرب می‌تواند در همین فاصله، فایل عادی را با symlink جایگزین کند.
2. دنبال‌کردن symlink هنگام استخراج: هنگام استخراج آرشیو روی میزبان، مسیرهای symlink به بیرون از دایرکتوری مقصد اشاره می‌کنند و چک مسیر کافی اعمال نشده است.

نتیجه: مهاجمی که روی کانتینر کنترل دارد — مثلاً کاربری که اجازهٔ اجرای ایمیج دلخواه در CI را دارد — می‌تواند هر فایل میزبان، از /etc/cron.d تا باینری‌های سیستمی، را بازنویسی کند. اشارهٔ گزارش Imperva به /usr/bin/runc تصادفی نیست: runc همان باینری است که هنگام اجرای هر کانتینر با سطح root فراخوانی می‌شود و بازنویسی آن یعنی ماندگاری کامل روی میزبان.

زنجیرهٔ TOCTOU و symlink در ساخت و استخراج آرشیو tar — Docker Inc.

#چرا مهم است؟

docker cp یکی از آن دستورهایی است که در پایپ‌لاین‌های CI برای استخراج آرتیفکت و در تحلیل‌های فارنزیک برای خروج شواهد از کانتینر به‌صورت روتین و بدون فکر استفاده می‌شود. دقیقاً همین «بی‌خطر فرض کردن» است که CopyEscape را خطرناک می‌کند: بردار حمله نه یک API تازه، که عادت روزمرهٔ مهندسان است.

نکتهٔ کمتر دیده‌شده اما مهم، پوشش sbx cp است: سندباکس‌های داکر که برای اجرای امن کدهای تولیدشده توسط agentهای هوش مصنوعی طراحی شده‌اند، از همین نقص رنج می‌برند. یعنی درست در قلب جریان کاری «اجرای کد نامطمئن LLM در سندباکس»، خود سندباکس می‌توانست به مسیر فرار تبدیل شود. این تقابل — سندباکسی که قرار بود دیوار باشد و در شد — باید در طراحی زیرساخت agentها جدی گرفته شود.

اقدامات فوری: ارتقا به Engine/CLI 29.7.2، Desktop 4.86.0 و Sandboxes 0.38.0؛ بازبینی هر جایی که docker cp از کانتینرهای نامطمئن انجام می‌شود؛ و بررسی اینکه آیا در پایپ‌لاین شما کاربران می‌توانند ایمیج دلخواه اجرا کنند.

#اعداد و ارقام

• ۱۰ اوت ۲۰۲۶: افشای CVE-2026-17106 توسط Imperva Red Team
• ۳ محصول وصله‌شده: Engine/CLI 29.7.2، Desktop 4.86.0، Sandboxes 0.38.0
• PoC عمومی: موجود و بازتولیدشده تا ۱۸ اوت
• سطح دسترسی نهایی: اجرای کد با root روی میزبان

#مدل تهدیده و درس‌ها

نکتهٔ ظریف CopyEscape در مدل تهدیدهٔ آن است: مهاجم نیازی به اجرای کد روی میزبان ندارد؛ کافی است کانتینری تحت کنترل او روی سیستمی اجرا شود که کاربر یا سرویسی روی آن docker cp انجام می‌دهد. در محیط‌های CI مشترک، هر توسعه‌دهنده‌ای که بتواند ایمیج دلخواه اجرا کند، بالقوه این شرط را دارد. درس بلندمدت برای پلتفرم‌ها این است که عملیات «انتقال فایل» میان مرزهای اعتماد باید با همان جدیتِ اجرای کد طراحی شود؛ استخراج آرشیو از منبع نامطمئن، خود یک primitive امنیتی است نه یک کار خدماتی.

#منابع

• Imperva Blog — CopyEscape
• GitHub Advisory GHSA-hfg8-hc9c-6c3h