شناسههای پنهان در پشت نشان تأیید گیتهاب
پژوهشهای اخیر ثابت کردهاند که هش یک کامیت امضا شده، آن شناسه منحصر به فردی نیست که بسیاری از جامعه توسعهدهندگان به آن اعتماد دارند. محققان نشان دادهاند هر کسی میتواند با تغییر جزئی در ساختار امضا، یک کامیت کپی با همان فایلها، نویسنده و تاریخ ایجاد کند. پلتفرم میزبانی کد بدون تشخیص تفاوت فنی، برچسب «تأیید شده» را به هش جدید میزند. بازبینان تمامی فیلدها را بررسی میکنند و همگی صحیح به نظر میرسند، تنها شناسه هش متفاوت است.
این قابلیت چه خطراتی برای زنجیره تأمین نرمافزار ایجاد میکند؟ اگر یک کامیت مخرب را بر اساس هش مسدود کنید، مهاجم میتواند دقیقاً همان فایلها را با هشی جدید و همچنان «تأیید شده» منتشر کند. لیستهای سیاه، سیستمهای حذف تکرار (Deduplication) و روزنامههای اثبات منشأ که به هش تکیه دارند، عملاً فلج میشوند. نسخههای آینهای مخرب یا دستکاری شده هم میتوانند به راحتی کامیتهای معتبراً امضا شدهای را به دست توسعهدهندگان برسانند که هش آنها با مخزن اصلی گیتهاب مطابقت ندارد.
چه چیزی در اینجا اتفاق نمیافتد؟
پیش از هرگونه نگرانی باید تأکید کرد این پدیده یک حمله تزریق کد مخرب نیست. محتوا در هر نسخه دقیقاً یکسان است و هشی که قبلاً قفل کردهاید یا محتوا مورد تأیید را دریافت میکند یا درخواست را رد خواهد کرد. این خراش، نقصی در نحوه تعریف نشان «تأیید شده» توسط پلتفرم میزبانی کد است و رفع آن کاملاً در دستان گیتهاب قرار دارد. بهروزرسانی خاصی برای مخازن شخصی کاربران نیاز نیست.
مکانیسم حمله و ریشه فنی
یافتههای جیکوب گینسین، پژوهشگر دکتری دانشگاه کارنگی ملون و حسابرس رمزنگاری در شرکت Cure53، در مقالهای منتشر شده در arXiv به تفصیل شرح داده شده است. ابزار عمومی همراه این پژوهش سه روش حمله را شبیهسازی میکند. از آنجایی که هر کامیت والد خود را با هش میشناسد، تغییر یک کامیت زنجیرهای از هشهای جدید را در کامیتهای بعدی ایجاد میکند. گینسین این پدیده را «قابلیت تغییرپذیری زنجیره هش» مینامد.
علت اصلی، قابل دستکاری بودن امضاهاست. هش یک کامیت بر روی همه بایتهای درون آن، از جمله دادههای خام امضا در هدر، محاسبه میشود. بسیاری از امضاها را میتوان به شکل متفاوت اما همچنان معتبر بازنویسی کرد و تغییر این بایتها هش را بدون دست زدن به یک خط کد تغییر میدهد.
سه مسیر نفوذ به سیستم اعتبارسنجی
محققان تمام طرحهای GPG و S/MIME که گیتهاب بررسی میکند، پوشش دادهاند:
- کلیدهای ECDSA: با استفاده از جبر منحنی بیضوی، ضریب s در امضا معکوس میشود. هر دو فرم از نظر ریاضی معتبر هستند. این تغییر توسط دستور محلی git verify-commit و الگوریتم گیتهاب رد نمیشود.
- کلیدهای RSA و EdDSA: اضافه کردن یک فیلد نادیدهگرفتهشده به بخش «هشنشده» امضا، باعث تغییر بایتهای کامیت و در نتیجه هش آن میشود. هر دو فرم محلی و آنلاین امضا را تأیید میکنند.
- کلیدهای S/MIME (X.509): بازنویسی فیلد طول در ساختار DER به فرمی غیراستاندارد. بررسیهای محلی سختگیرانه این مورد را رد میکنند، اما گیتهاب همچنان نشان تأیید را صادر میکند.
ریشه مشترک این سه مسیر این است که گیتهاب پیش از بررسی، امضای دریافتی را نرمالسازی نمیکند. فرمتهای غیراستاندارد S/MIME، فیلدهای اضافی OpenPGP و مقادیر غیرمتعارف ECDSA بیقید و شرط پذیرفته میشوند. پلتفرم نیز پس از ثبت هش، دیگر آن را بازبینی نمیکند. در نتیجه حتی پس از لغو کلید امضا، کامیت بهطور مطلق «تأیید شده» باقی میماند.
تفاوت کلیدی با برخورد هش (Collision)
باید دقیق دانست که این پدیده اصلاً مربوط به برخورد هش نیست. الگوریتمهای SHA-1 یا SHA-256 آسیب ندیدهاند و بحث تبدیل گیت به SHA-256 نیز کاملاً بیاهمیت است. در اینجا دو کامیت مختلف به یک هش نمیرسند؛ بلکه یک کامیت واحد به چندین فرمت بایتی معتبر بازنویسی میشود که هر کدام شناسه منحصر به فرد خود را میسازند. این حرکت سابقهای قدیمی دارد. شبکه بیتکوین سالها پیش با تقارن ECDSA در تراکنشها دستوپنج نرم کرد. راهحل ساده پذیرش تنها فرم «کمتوان» (Low-S) بود که بعداً به استاندارد جهانی تبدیل شد.
جامعه توسعهدهندگان و شرکتهای میزبانی کد باید بدون معطلی، لایههای اعتبارسنجی نشانهای تأیید را بافتمند و سختگیرانهتر کنند. ایستاده در برابر این نوع قابلیت تغییرپذیری، تضمین میکند که برچسبهای اطمینان روی پلتفرمها، پشتوانه واقعی امنیت زنجیره تأمین نرمافزار باقی بمانند و نه تنها یک جلوه ظاهری.
