باگ ۱۵۰ هزار دلاری در Private Cloud Compute اپل
خلاصهٔ کاملتر
به گفتهٔ Drinor Selmanaj، بنیانگذار Sentry، این آسیبپذیری قلب زیرساخت هوش مصنوعی اپل رو هدف گرفته. Private Cloud Compute یا PCC همون سروریه که درخواستهای سنگین Apple Intelligence که رو گوشی جا نمیشن اونجا پردازش میشن. وعدهٔ حریم خصوصی اپل روی سه پایه بنا شده: نودها stateless هستن و چیزی نگه نمیدارن، قبل از ارسال داده بهصورت رمزنگاریشده attest میشن، و لاگها از مسیر sealed observability فقط با فیلدهای از پیش تأییدشده بیرون میرن.
نقطهٔ ضعف تو پنجرهٔ بوت بود. اولین پروسهٔ فضای کاربر روی هر نود، darwin-init با PID 1 و دسترسی root اجرا میشه: پیکربندی رو میگیره، کریپتکسها (بستههای امضاشدهٔ کد و داده) رو دانلود و استخراج و نصب میکنه و بعد یه ریاستارت فضای کاربر میزنه. نویسنده میگه هرچی این پروسه رو دیسک بذاره، وقتی نود بالا میاد سر جاشه — قبل از اینکه هیچ سرویس نظارتیای فعال شده باشه.
موقع استخراج، darwin-init فقط چهار بایت اول فایل رو میخونه تا تصمیم بگیره از کدوم extractor استفاده کنه. امضای فرمت tar تو بایت ۲۵۷ قرار داره، یعنی خیلی دورتر از این پنجرهٔ چهاربایتی؛ پس یه آرشیو tar با هیچکدوم از حالتهای شناختهشده مطابقت نمیکنه و میافته تو شاخهٔ پیشفرض و تابع عمومی extract(to:). مشکل دقیقاً همونجاست: اسم هر ورودی مستقیم از خود آرشیو خونده و بدون هیچ اعتبارسنجی به مسیر خروجی چسبونده میشه.
guard let cStr = archive_entry_pathname(entry) else { continue }
let str = String(cString: cStr)
let pathname = path.appending(str)
archive_entry_set_pathname(entry, pathname.description)هیچکدوم از فلگهای امنیتی libarchive هم ست نشده بودن، پس کتابخونه هرجا که اسم ورودی اشاره میکرد فایل مینوشت و خروجی موفق برمیگردوند. دو تا محافظ دیگه هم عملاً بیاثر بودن: تابع PrivateCloudOSValidator.validate(cryptexConfig:) تو سورس منتشرشده بدنهش خالیه، و مقدار sha256 هر کریپتکس اختیاریه، یعنی وقتی خود مهاجم پیکربندی رو میده میتونه بررسی یکپارچگی رو کلاً حذف کنه.
نویسنده آرشیوی ساخت که همزمان هم یه بستهٔ کریپتکس معتبر بود تا بررسیهای نصب پاس بشه و بوت هنگ نکنه، و هم چند ورودی داشت که با بالا رفتن از مسیر، فایلها رو روی ولوم دادهٔ ماندگار مینوشتن. با همین دسترسی، پیکربندی سرویس لاگ داخلی splunkloggingd رو ساخت و جریان لاگ نود رو به سرور خودش برگردوند؛ بعد از فعال کردن استنتاج هم متادیتای هر درخواست مثل requestID و workloadType و حتی شمارش توکنها تو همون کانال ظاهر شد.
نکتهٔ نگرانکنندهتر اینه که تو مقایسهٔ بوت سالم و بوت آلوده، بستههای attestation عملاً یکسان درمیاومدن: attestation نرمافزار نصبشده رو میسنجه ولی وضعیت فایلهای ولوم داده جزو زنجیرهٔ تأیید نیست. نویسنده یادآوری میکنه این یه کلاس آسیبپذیری سیسالهست، از همون خانوادهٔ Zip Slip و CWE-22، و همین نشون میده امن کردن کل خط لولهٔ استنتاج بهاندازهٔ امن کردن خود مدل مهمه.
نکات کلیدی:
- آسیبپذیری path traversal در darwin-init، اولین پروسهٔ روت نودهای PCC، با شناسهٔ CVE-2026-20685
- علت: انتخاب extractor فقط بر اساس چهار بایت اول فایل و نبود اعتبارسنجی روی اسم ورودیهای آرشیو
- محافظهای پشتیبان هم بیاثر بودن: تابع اعتبارسنجی خالی و اختیاری بودن دایجست sha256
- تأثیر: بازگردانی لاگ و تلهمتری استنتاج Apple Intelligence به سرور مهاجم و نشت متادیتای هر درخواست
- attestation فقط نرمافزار نصبشده رو تأیید میکنه و تغییر فایلهای ولوم داده رو نمیبینه
- اپل اون رو از نوع افشای اطلاعات با CVSS 6.5 دستهبندی کرد، تو نسخههای 5E290.3 به بعد رفعش کرد و ۱۵۰ هزار دلار جایزه داد




