آسیبپذیری Phantom Patch در گیتهاب
خلاصهٔ کاملتر
گیتهاب و خیلی از سرویسهای مشابه، برای هر commit یه URL با پسوند .patch دارن که یه خروجی متنی استاندارد از تغییرات اون commit میده. این روش قدیمیترین و سادهترین راه انتقال پچ بین ماشینهاست؛ یه wget یا curl میزنی، فایل رو میگیری، بعد با GNU patch اعمال میکنی. اما یه محقق به اسم Egor Kovetskiy یه چیز نگرانکننده تو این جریان پیدا کرده.
موضوع اینه که GNU patch وقتی داره یه فایل .patch رو پردازش میکنه، تفاوتی بین «diff واقعی commit» و «diffای که داخل متن commit message نوشته شده» قائل نمیشه. یعنی اگه یه نفر یه diff جعلی رو داخل توضیح commit خودش بنویسه، ابزار patch هر دو رو با هم اجرا میکنه.
محقق یه دمو عمومی ساخته که این رو نشون میده. commit اصلی فقط یه فایل به اسم readme.md میسازه. اما داخل commit message، یه diff جعلی برای ساخت فایل SHOULD_NOT_BE_HERE.md هم وجود داره. وقتی این پچ رو با GNU patch اعمال میکنی، هر دو فایل ساخته میشن، در حالی که SHOULD_NOT_BE_HERE.md اصلاً بخشی از commit واقعی نبوده.
خطر اصلی اینجاست که این فایل «فانتوم» میتونه هر چیزی باشه. محقق در تستهای محلی خودش تونسته مسیر git/hooks/post-applypatch. رو هدف بگیره؛ یعنی میشه یه git hook مخرب رو از این طریق روی سیستم قربانی نصب کرد. git hook ها اسکریپتهایی هستن که خودکار در مراحل مختلف git اجرا میشن، پس یه hook آلوده میتونه خطر جدی باشه.
ابزارهای git apply و git am یه مقدار بهتر رفتار کردن؛ حداقل مسیرهای داخل .git/ رو رد کردن. اما اونا هم همچنان diff جعلی رو برای فایلهای معمولی اعمال کردن. git cherry-pick چون مستقیم با آبجکتهای گیت کار میکنه، اصلاً درگیر این مشکل نمیشه.
مشکل اصلی اینه که فرمت .patch که گیتهاب خروجی میده، هیچ جداکننده مشخصی بین «محتوای commit message» و «بخش diff واقعی» نداره که GNU patch بتونه به راحتی تشخیص بده. از دید امنیتی، هر کسی میتونه یه commit ظاهراً بیخطر بسازه که وقتی patch ش رو اعمال میکنی، فایلهای اضافهای که هیچوقت در UI گیتهاب نشون داده نمیشن رو روی سیستمت بنویسه.
هنوز مشخص نیست که مشکل از کجاست؛ آیا GNU patch باید هوشمندتر عمل کنه؟ آیا گیتهاب باید خروجی .patch ش رو ایمنتر بکنه؟ یا اصلاً خود استاندارد فرمت patch باید آپدیت بشه؟ فعلاً جواب روشنی وجود نداره. اما این ماجرا یه یادآوری مهمه که حتی ابزارهای خیلی قدیمی و ساده مثل wget + patch هم میتونن attack vector باشن.
نکات کلیدی:
- گیتهاب و سرویسهای مشابه برای هر commit یه فایل .patch عمومی دارن
- GNU patch نمیتونه بین diff داخل commit message و diff واقعی فرق بذاره
- یه مهاجم میتونه فایلهای مخرب رو از این طریق روی سیستم قربانی بنویسه بدون اینکه در UI گیتهاب دیده بشه
- git hook های مخرب هم میتونن از این روش نصب بشن
- git apply و git am مسیرهای .git/ رو رد میکنن ولی فایلهای معمولی رو همچنان میپذیرن
- هنوز مشخص نیست مشکل از GNU patch هست، GitHub، یا فرمت patch
