xz-utils؛ وقتی خطر از خود نگهدارندهست
خلاصهٔ کاملتر
مارس ۲۰۲۴، یه مهندس به اسم Andres Freund متوجه شد اتصال SSH به سرور تستش حدود ۵۰۰ میلیثانیه کندتر شده. همین رو ول نکرد و تهتوش رو درآورد: یه بکدور توی xz-utils، کتابخونهٔ فشردهسازیای که تقریباً هر سیستم لینوکسی بهش وابستهست. اگه به نسخههای پایدار میرسید، به مهاجم روی بخش بزرگی از اینترنت دسترسی root از راه دور میداد.
نکتهای که نویسنده روش تأکید میکنه اینه که این یه باگ نبود، یه ربایش اعتماد بود. یه حساب به اسم Jia Tan از ۲۰۲۱ کمکم با پچهای منطقی و کمک توی پروژه اعتماد جمع کرد تا کو-مِینتینر شد. بعد بکدور رو نه توی سورس گیت، بلکه توی ماکروهای m4 سیستم بیلد گذاشت؛ یعنی سورس روی گیتهاب تمیز بود و فقط تاربال انتشار آلوده بود.
به گفتهٔ نویسنده، اسکنرهای زنجیره تأمین فقط نسخهٔ توی lockfile رو با دیتابیس CVEها مقایسه میکنن. این یعنی به سؤال «این نسخه بدِ شناختهشدهست؟» جواب میدن، نه «این نسخه امنه؟». روز قبل از افشا، هر اسکنری xz 5.6.0 رو تمیز گزارش میکرد، چون نه CVE داشت نه سابقهٔ بد.
نویسنده میگه ابزارهای جدید یه لایه فراتر از CVE اضافه کردن: فیدهای بلادرنگ مثل OSV که سریعتر آپدیت میشن، بررسی اسکریپتهای postinstall (که چند حملهٔ npm مثل دستکاری lottie-player و solana web3.js ازش استفاده کردن)، و سیگنالهای تغییر نگهدارنده مثل ایمیل یا کلید امضای جدید و ریتم انتشار غیرعادی.
جمعبندی نویسنده اینه که امنیت زنجیره تأمین یه اسکن یکباره سر CI نیست، یه نظم نگهداری مداومه؛ چون lockfile فصلی آپدیت میشه ولی تهدید هر روز تازهست. سه کار عملی پیشنهاد میده: وابستگیهای مستقیم رو پین کن، هر تغییر lockfile توی هر PR مرور بشه، و برای زبونهایی که باهاش کار میکنی فید بلادرنگ بگیر.
نکات کلیدی:
- بکدور xz-utils یه ربایش اعتماد نگهدارنده بود، نه آسیبپذیری کد
- اسکنر CVE فقط چیز «شناختهشده بد» رو میگیره، پس قبل از افشا کور بود
- بکدور توی سیستم بیلد (ماکروهای m4) بود، نه سورس گیت
- فید بلادرنگ، بررسی postinstall و سیگنال تغییر نگهدارنده شکاف رو کم میکنن
- وابستگی مستقیم رو پین کن و هر دیف lockfile رو مرور کن
