خبر و تحلیل ابزارها و افزونه‌ها کسب‌وکار آنلاین

جعل نشان تأیید گیت‌هاب؛ چگونه کامیت‌های تأییدشده با شناسه‌ای جدید ساخته می‌شوند؟  

نقص در سیستم گیت‌هاب
هوشیار ذوالفقارنسب
زمان مطالعه ۳ دقیقه
بازبینی: دانیال طبایی
صحت سنجی شده

یافته‌های پژوهشی جدید نشان می‌دهد در برخی شرایط می‌توان از یک کامیت امضاشده در گیت‌هاب، نسخه‌ای دیگر با همان محتوا و امضای معتبر، اما با هش متفاوت ساخت. در این حالت، با وجود تغییر شناسه، نشان سبز رنگ تأییدشده (Verified)1 همچنان حفظ می‌شود. این نقص ساختاری، فرض رایج مبنی بر کافی بودن شناسه کامیت برای شناسایی یکتایی تغییرات را در مدیریت کدهای نرم‌افزاری به چالش می‌کشد؛ موضوعی که فرض رایج درباره یکتا بودن هش کامیت‌های امضاشده را به چالش می‌کشد.

مشکل چیست و چگونه کار می‌کند؟

در دنیای برنامه‌نویسی، توسعه‌دهندگان از امضای دیجیتال برای اثبات اصالت کامیت های خود استفاده می‌کنند و گیت‌هاب نیز به این کدها نشان تأیید می‌دهد. با این حال، یکی از پژوهشگران امنیتی دانشگاه کارنگی ملون، کشف کرد که در برخی شرایط می‌توان بدون تغییر محتوای کد، نسخه‌ای دیگر از همان کامیت با شناسه‌ای متفاوت اما همچنان دارای امضای معتبر ایجاد کرد. 

این مشکل از مفهومی به نام انعطاف‌پذیری امضا (Signature Malleability) سرچشمه می‌گیرد. در سیستم مدیریت نسخه گیت، هش نهایی بر اساس تمام محتویات فایل از جمله بایت‌های خود امضا محاسبه می‌شود. با این نقص، مهاجم می‌تواند بدون تغییر دادن کدهای اصلی برنامه‌نویس، ظاهر بایت‌های امضا را دستکاری کند. در نتیجه، شناسه کامیت تغییر می‌کند، در حالی که محتوای کد ثابت می‌ماند. 

در ادامه، پژوهشگران نشان داده‌اند این رفتار در چند استاندارد رایج امضای دیجیتال قابل بازتولید است. در همه این موارد، ظاهر داده‌های امضا تغییر می‌کند، اما اعتبار ریاضی امضا حفظ می‌شود. در این شرایط، گیت‌هاب همچنان امضای دیجیتال را معتبر تشخیص می‌دهد و نشان تأیید را حفظ می‌کند.

چرا این نقص ساختاری خطرناک است؟

خبر خوب این است که مهاجم نمی‌تواند با استفاده از این نقص، کدهای مخربی را وارد پروژه کند، زیرا هرگونه تغییر در فایل‌های اصلی نرم‌افزار باعث باطل شدن قطعی امضا می‌شود؛ اما خطر اصلی در دور زدن ابزارهای دفاعی خودکار نهفته است. اگر یک تیم امنیتی، کدی مخربی را شناسایی کند و هش آن را در لیست سیاه قرار دهد، مهاجم می‌تواند با بازنویسی امضا، شناسه جدیدی برای همان کد تولید کند. در نتیجه، سامانه‌هایی که فقط بر اساس هش عمل می‌کنند ممکن است نسخه جدید را شناسایی نکنند.

تا رفع مشکل، برنامه‌نویسان چه کنند؟

پیش از این نیز در نوشدارو پرداختیم که چگونه ده‌ها پروژه متن‌باز مایکروسافت در گیت‌هاب به بدافزار آلوده شد و لزوم توجه به امنیت مخازن کد را بیش از پیش نمایان کرد. این پژوهش نشان می‌دهد اتکا به شناسه کامیت یا نشان تأیید به‌تنهایی برای تضمین امنیت زنجیره تأمین نرم‌افزار کافی نیست. تا زمان ارائه راهکار از سوی گیت‌هاب و سایر ابزارها، توسعه‌دهندگان باید از روش‌های تکمیلی اعتبارسنجی نیز استفاده کنند. 

  1. نشان Verified در گیت‌هاب به این معناست که امضای کامیت از نظر رمزنگاری قابل تأیید بوده است؛ نه اینکه خود کد الزاماً امن است یا آن هش تنها نماینده ممکن برای آن محتواست. ↩︎
بازبینی: دانیال طبایی

تازه‌ترین مطالب

مطالب پرنگاه

ویدیوهای نوشدارو

ویدیو های بیشتر
مشاهده همه ویدئوها

حکایت‌های کوتاه، حقیقت‌های بزرگ

در این بخش، به بررسی دقیق و جامع نشانه‌ها و رفتارهایی می‌پردازیم که ممکن است به کلاهبرداری آنلاین مرتبط باشند. شناخت این موارد می‌تواند به شما کمک کند.

ویدیو های بیشتر

منابع

  1. The Hacker News
    https://thehackernews.com/2026/07/github-verified-commits-can-be.html
  2. arXiv
    https://arxiv.org/abs/2607.02820
  3. GBHackers News
    https://gbhackers.com/duplicate-verified-github-commits-using-signature-malleability/