Miri دایرکتوری کششدهٔ `target/` را به یک مرز محرمانگی تبدیل میکند
افشای امنیتی جدید Rust نشان میدهد ترکیب `cargo miri`، secrets با دامنهٔ گسترده و کش قابلخواندن برای pull request چگونه میتواند به افشای اعتبارنامهها منجر شود. تیمهای Rust در ICP باید مرزهای CI را ممیزی کنند، کشهای مشکوک را پاک کنند و secrets احتمالی را بچرخانند.

یک افشای امنیتی جدید در Rust، یکی از بهینهسازیهای معمول CI را با دقت بیشتری زیر ذرهبین میبرد: دایرکتوری کششدهٔ target/ میتواند به یک artifact حاوی secrets تبدیل شود.
تیم واکنش امنیتی Rust در ۲۱ سپتامبر اعلام کرد که Miri همهٔ متغیرهای محیطی را در target/ ذخیره میکرد تا مقادیر لازم برای ساخت بین اجراها باقی بمانند. این رفتار زمانی خطرناک میشود که workflow همزمان secrets را در اختیار مرحلهٔ Miri بگذارد، target/ را کش کند و اجازه دهد jobهای pull request آن کش را بخوانند. در چنین پیکربندیای، یک pull request میتواند دادهای را که در اجرای مورداعتماد قبلی نوشته شده بازیابی کند.
این موضوع برای مخازن ICP که از ابزارهای Rust برای canister، مؤلفههای nightly یا کشکردن گسترده در GitHub Actions استفاده میکنند اهمیت ویژهای دارد. مسئله این نیست که مفسر Miri ذاتاً ابزار exfiltration است؛ شکست اصلی، ناهماهنگی مرزهاست: فرایندی که به اعتبارنامهها دسترسی دارد، در دایرکتوریای مینویسد که بعداً بهعنوان build state قابلاشتراک تلقی میشود.
راهکار کوتاهمدت تیم Rust، محیط ذخیرهشده توسط Miri را به متغیرهای CARGO_* محدود میکند، بهجز CARGO_*_TOKEN، و همچنین OUT_DIR را نگه میدارد. تیم اعلام کرد این اصلاح قرار بود در نسخهٔ nightly با تاریخ ۲۲ سپتامبر ۲۰۲۶ عرضه شود. همچنین توصیه میکند کش آن job غیرفعال شود، secrets از Miri دور نگه داشته شوند یا Miri موقتاً غیرفعال شود. پس از مهار مشکل، نگهدارندگان باید کش را پاک و اعتبارنامههایی را که ممکن است افشا شده باشند تعویض کنند.
مستندات GitHub توضیح میدهد که secrets مربوط به Actions در اجرای workflow تزریق میشوند و GitHub فقط برخی مقادیر حساس را در logها بهطور خودکار مخفی میکند. این حفاظت، فایلهای نوشتهشده توسط ابزارها را امن نمیکند: secret کپیشده در target/ مسئلهٔ artifact است، نه صرفاً مسئلهٔ مخفیسازی log.
برای یک workflow مبتنی بر Rust در ICP، ممیزی عملی دامنهٔ مشخصی دارد. همهٔ فراخوانیهای cargo miri را پیدا کنید، بررسی کنید job مربوطه به secrets مخزن، سازمان، محیط، cloud، registry یا deployment دسترسی دارد یا نه، و ببینید آیا target/ برای pull requestها کش یا restore میشود. jobهای دارای اعتبارنامه را از jobهایی که کش قابلاستفادهٔ مجدد مینویسند جدا کنید. اگر کشی با این ترکیب پرخطر در دسترس بوده است، پیش از پاک تلقیکردن workflow آن را حذف کنید.
یک caveat مهم وجود دارد: تیم Rust میگوید اسکن اکوسیستم ممکن است کامل نبوده باشد؛ بنابراین نبودن نام یک مخزن در گزارش، دلیل امنبودن آن نیست. caveat دیگر این است که تغییر منتشرشده اصلاح کوتاهمدت Miri است و روش بلندمدت Miri و Cargo برای تعیین محیط موردنیاز هنوز حل نشده است. بنابراین قاعدهٔ مهندسی گستردهتر پس از این patch هم پابرجاست: secrets را در اختیار jobی نگذارید که artifactهایی را برای استفادهٔ دوبارهٔ غیرقابلاعتماد یا نیمهقابلاعتماد تولید میکند.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.


