فرار از سندباکس در Cursor، Codex، Gemini CLI و Antigravity
هوش مصنوعیخلاصهٔ کاملتر
تیم تحقیقاتی Pillar تو یه پروژهٔ چندماهه، فرار از سندباکس و دور زدن مرزها رو تو Cursor، Codex، Gemini CLI و Antigravity پیدا و بازتولید کرده و نتیجه رو به شکل یه سری مطلب («هفتهٔ فرار از سندباکس»، هر روز یه مورد) منتشر میکنه. به گفتهٔ نویسندهها نکتهٔ مشترک تقریباً همهٔ موارد اینه که عامل لازم نبود خودِ سندباکس رو بشکنه؛ کافی بود چیزی بنویسه که یه کامپوننت مورداعتمادِ بیرون سندباکس بعداً اجرا، بارگذاری یا اسکنش کنه.
جمعبندیشون یه جملهست: شعاع انفجار یه عامل، پروسهٔ عامل نیست — هرچیزیه که عامل میتونه بنویسه و هاست بعداً بهش اعتماد میکنه. مرز سندباکس دستکم سه لایه داره: اجرای مستقیم (چی میتونه اجرا کنه)، نوشتن در workspace (چه فایلی میتونه بسازه یا عوض کنه) و اعتماد هاست (کامپوننتهای بدون سندباکس بعداً با اون فایلها چی کار میکنن). جالبترین شکستها تو لایهٔ سومه.
چهار الگوی تکرارشوندهٔ شکست: سندباکسهای denylist که از پیچیدگی سیستمعامل عقب میمونن؛ کانفیگهای workspace که در واقع کد اجراشدنیان؛ allowlistهای «دستور امن» که به نام دستور اعتماد میکنن نه به نحوهٔ فراخوانیش؛ و دیمنهای محلی پرقدرت که کلاً بیرون سندباکس نشستهان. نویسندهها در مورد اولی جملهٔ تندی دارن: یه پروفایل allow-by-default سندباکس نیست، فهرستی از چیزهاییه که یادِ کسی مونده ببنده و همیشه یه قلم کمه.
نمونههای واقعی همین الگوها: پروفایل Seatbelt از نوع allow-by-default در Antigravity که قابلیتهایی از سیستمعامل رو باز گذاشته بود؛ دسترسی به سوکت Docker که به یه محیط اجرای بدون سندباکس تبدیل شد (وصله شده، با advisory)؛ ویرایش مفسر داخل virtualenv که افزونهٔ پایتونِ بدون سندباکسِ خود IDE بعداً موقع discovery اجراش کرد؛ کانفیگ hook داخل workspace که به اجرای دستور بدون سندباکس رسید؛ و یه task config در .vscode که هاست خودش بعداً اجراش کرد.
مورد git show در Codex نمونهٔ خوب «امن بهاسم»ه: اسم دستور read-only به نظر میرسید، ولی فراخوانی واقعی اینطور نبود. نویسندهها میگن گیت پر از فلگهاییه که رفتار رو عوض میکنن — یه دستور میتونه بیخطر به نظر برسه و همون موقع فایل بنویسه، کانفیگ بار کنه، helper صدا کنه یا hook اجرا کنه. پس سؤال درست این نیست که «آیا git show امنه»، بلکه اینه که دقیقاً چه فراخوانیای با چه آرگومانهایی، تو چه دایرکتوری، با چه کانفیگی و با چه عوارضی اجرا میشه.
چرا این مهمه: به گفتهٔ نویسندهها ابزارهای عاملی روی همون ماشینی کار میکنن که کد، کلید SSH، توکن کلاد، سشن مرورگر، حق انتشار پکیج و دسترسی production کنار همان، و بهطور روتین ورودی نامعتمد (README، ایشو، داکس، دیف، لاگ، محتوای وب) رو پردازش میکنن. تو این شرایط prompt injection دیگه یه مسئلهٔ چتبات نیست؛ یه دستور خرابکارانه میتونه به یه اکشن محلی روی ماشین توسعهدهنده تبدیل شه.
توصیهٔ عملی مقاله برای تیمهای امنیتی اینه که مکالمهٔ خرید با «سندباکس داری؟» تموم نشه. سؤالهای لازم: عامل چی میتونه بنویسه؟ کدوم کامپوننتهای هاست به اون نوشتهها اعتماد میکنن؟ به چه دیمنهای محلی دسترسی داره؟ کدوم دستورها از تأیید کاربر رد میشن و چرا؟ پالیسی روی نام دستور اعمال میشه یا روی عوارض واقعی؟ محصول میتونه فایل ساختهشدهٔ کاربر رو از فایل ساختهشدهٔ عامل تشخیص بده؟ و وقتی یه helper مورداعتماد چیزی رو اجرا میکنه، چه telemetryای ثبت میشه؟
نکات کلیدی:
- یافتهها روی Cursor، Codex، Gemini CLI و Antigravity؛ چند مورد وصله و advisory گرفته
- الگوی مشترک: عامل چیزی مینویسه که یه کامپوننت بیرون سندباکس بعداً اجراش میکنه
- کانفیگ پروژه روی ماشین توسعهدهنده عملاً زیرساخت اجراشدنیه
- allowlist بر اساس نام دستور کافی نیست؛ پالیسی باید عوارض واقعی رو ببینه
- دیمنهای محلی مثل Docker یه محیط اجرای دومِ خارج از سندباکسان
