جمعه, مهر ۳, ۱۴۰۵

کلادفلر نقصی را برطرف کرد که به یک کانتینر اجازه می‌داد داده‌های باقی‌مانده روی دیسکِ مشتری دیگر را بخواند

0
3
کلادفلر نقصی را برطرف کرد که به یک کانتینر اجازه می‌داد داده‌های باقی‌مانده روی دیسکِ مشتری دیگر را بخواند.

یک نقص امنیتی در Cloudflare Containers به یک مشتریِ دارای اشتراک پولی اجازه می‌داد داده‌هایی را بخواند که کانتینرهای مشتریان دیگر پیش‌تر روی همان سرور باقی گذاشته بودند. Cloudflare و پژوهشگرانی که این آسیب‌پذیری را کشف کردند، روز پنج‌شنبه این موضوع را اعلام کردند.

این داده‌ها مربوط به فضای دیسکی بود که کانتینرهای قبلی استفاده کرده و سپس آزاد کرده بودند، نه هیچ workload فعالی. همچنین مهاجم نمی‌توانست انتخاب کند که داده‌های کدام مشتری را دریافت کند. طبق اعلام Cloudflare، این شرکت آسیب‌پذیری را در سراسر سرویس خود برطرف کرده و مشتریان نیازی به انجام هیچ اقدامی ندارند.

سرویس Cloudflare Containers برنامه‌های مشتریان را داخل کانتینرهایی اجرا می‌کند که روی سرورهای مشترک میان چندین حساب کاربری قرار دارند و این Cloudflare است، نه مشتری، که سرور میزبان را انتخاب می‌کند. Cloudflare Sandboxes نیز که روی Containers اجرا می‌شود و به‌عنوان محیطی امن برای اجرای کدهای غیرقابل‌اعتماد، از جمله کدهای نوشته‌شده توسط عامل‌های هوش مصنوعی، ارائه می‌شود، تحت تأثیر این آسیب‌پذیری قرار داشت.

این نقص در تاریخ ۴ سپتامبر توسط Oren Yomtov از شرکت امنیتی Accomplish و از طریق برنامه Bug Bounty شرکت Cloudflare گزارش شد.

مشکل به نحوه پیکربندی دیسک‌های اشتراکی مربوط می‌شد. هر کانتینر یک دیسک دریافت می‌کند که با استفاده از قابلیتی در لینوکس به نام Thin Provisioning ساخته می‌شود؛ قابلیتی که فضای ذخیره‌سازی را در بلوک‌های ۶۴ کیلوبایتی تخصیص می‌دهد. وقتی یک کانتینر حذف می‌شد، بلوک‌های آن دوباره به یک pool مشترک میان حساب‌های مختلف مشتریان بازگردانده می‌شدند.

این pool طوری تنظیم شده بود که پیش از تحویل یک بلوک به کانتینر بعدی، عملیات پاک‌سازی یا Wiping آن بلوک انجام نشود؛ در حالی که حالت پیش‌فرض معمولاً پاک‌کردن بلوک پیش از استفاده مجدد است. بنابراین اگر یک کانتینر جدید فقط مقدار کمی داده در یک بلوک بازیافتی می‌نوشت، بخش باقی‌مانده بلوک همچنان می‌توانست حاوی داده‌های کانتینر قبلی باشد.

برای دسترسی به این داده‌ها، پژوهشگران یک بلوک کوچک ۴ کیلوبایتی را در فضای استفاده‌نشده نوشتند و سپس کل بلوک را مستقیماً در سطح خام دیسک دوباره خواندند. ۶۰ کیلوبایتی که خودشان روی آن چیزی ننوشته بودند، همچنان شامل بایت‌هایی متعلق به کانتینر قبلی بود.

در آزمایش‌هایی که روی محیط Production انجام شد، پژوهشگران اعلام کردند در ۱۸ مورد از ۲۴ آزمایش توانسته‌اند داده‌های باقی‌مانده را پیدا کنند؛ در هر مورد نیز سرور توسط Cloudflare انتخاب شده بود. همچنین این وضعیت روی ۲۰ مورد از ۲۲ ماشین زیرساختی در چهار قاره مشاهده شد.

به گفته Cloudflare، بلوک‌های بازیابی‌شده شامل ساختار دایرکتوری‌ها، صفحات پایگاه‌داده و حتی پایگاه‌های داده SQLite با ساختار کامل بودند. پژوهشگران نیز در گزارش خود به مواردی مانند فهرست دایرکتوری‌ها، پایگاه‌های داده SQLite، پروفایل‌های مرورگر Chromium، فایل‌های .env و فایل‌های حاوی Credential اشاره کرده‌اند و آن‌ها را فایل‌های متعلق به سایر مشتریان توصیف کرده‌اند.

پژوهشگران اعلام کردند اسکریپت‌های تحلیل آن‌ها فقط تعداد موارد و بررسی فرمت‌ها را در خروجی نمایش می‌داد و نه محتوای واقعی فایل‌ها را. همچنین داده‌هایی که برای Cloudflare ارسال کردند شامل هیچ نام، شناسه، Credential یا محتوای بازیابی‌شده متعلق به اشخاص ثالث نبود.

Cloudflare همچنین اعلام کرد پژوهشگران تأیید کرده‌اند داده‌های بازیابی‌شده محرمانه نگه داشته شده و پس از ارسال گزارش، به‌صورت امن حذف شده‌اند. پژوهشگران نیز نشان ندادند که این آسیب‌پذیری امکان تغییر داده‌های فعال مشتری دیگری یا از کار انداختن workload او را فراهم می‌کرده است.

Cloudflare این مشکل را در دو مرحله برطرف کرد. ابتدا قابلیت پاک‌سازی بلوک‌ها پیش از تخصیص مجدد دوباره فعال شد که باعث شد روش گزارش‌شده دیگر کار نکند. پژوهشگران در تاریخ ۱۴ سپتامبر تأیید کردند که Proof of Concept آن‌ها دیگر قادر به سوءاستفاده از آسیب‌پذیری نیست.

اما این تغییر، بلوک‌هایی را که از قبل در دیسک کانتینرهای در حال اجرا map شده بودند یا در cache لایه‌های Image آماده‌شده روی هر سرور قرار داشتند، پاک نمی‌کرد؛ بلوک‌هایی که یک کانتینر جدید ممکن بود آن‌ها را به ارث ببرد و بخواند. بنابراین Cloudflare تمام دیسک‌های کانتینرهای در حال اجرا را از چرخه خارج کرد و cacheهای مربوطه را نیز پاک کرد و در ساعات کم‌ترافیک، سرورها را به‌تدریج drain و restart کرد. این عملیات پاک‌سازی در تاریخ ۱۹ سپتامبر به پایان رسید و Cloudflare پنج روز بعد آسیب‌پذیری را به‌صورت عمومی افشا کرد.

Cloudflare اعلام کرد بررسی کرده است که آیا فرد دیگری نیز از این روش استفاده کرده یا خیر. این شرکت بر اساس Proof of Concept پژوهشگران و نسخه‌ای از حمله که مهندسان خودش بازسازی کرده بودند، Detection Signatureهایی ایجاد کرد و آن‌ها را روی رکوردهای فعالیت دیسکی که نگهداری کرده بود اجرا کرد. تنها مواردی که پیدا شد مربوط به آزمایش مجاز پژوهشگران و مهندسان خود Cloudflare بود و این شرکت اعلام کرد هیچ مدرکی ندیده که نشان دهد شخص دیگری از همین روش مشخص استفاده کرده باشد.

البته این نتیجه فقط رکوردهایی را پوشش می‌دهد که Cloudflare نگهداری کرده بود. این شرکت مشخص نکرده که این رکوردها مربوط به چه بازه زمانی بوده‌اند یا پیکربندی ناامن نخستین بار چه زمانی فعال شده بود؛ بنابراین از گزارش Cloudflare مشخص نیست این وضعیت برای چه مدت ادامه داشته است.

پژوهشگران که به‌طور جداگانه اعلام کرده‌اند همین نحوه پیکربندی دیسک روی محصول Cloudflare Browser Run نیز اثر گذاشته است، این نقص را ششمین مورد فرار از Code Sandbox توصیف کرده‌اند که از ماه ژوئیه تاکنون منتشر کرده‌اند؛ پس از یافته‌هایی در Anthropic Claude Cowork و Claude Code، ابزار خط فرمان Cursor، Docker و OpenAI Codex. در گزارش Cloudflare تنها از Containers و Sandboxes به‌عنوان محصولات تحت تأثیر نام برده شده و اشاره‌ای به Browser Run نشده است.

منبع: https://thehackernews.com/2026/09/cloudflare-fixes-flaw-that-let-one.html

مقاله قبلیهوش مصنوعی حملات را سریعتر، واقعی‌تر و هدف‌مندتر می‌کند

نظر بدهید

لطفا نظر خود را بنویسید
لطفا نام خود را اینجا وارد کنید

این سایت از اکیسمت برای کاهش جفنگ استفاده می‌کند. درباره چگونگی پردازش داده‌های دیدگاه خود بیشتر بدانید.