GitHub “Verified” chữ ký commit có thể bị viết lại để tạo hash mới
"Research found that GitHub can mark signed commits as "Verified" even when the same commit content is rewritten into a different hash via signature malleability. The issue affects ECDSA, RSA/EdDSA, and S/MIME verification paths, can undermine hash-based blocklists and provenance systems, and is fixed by canonicalizing signatures before trusting the commit hash; no CVE was assigned."
Tác động chủ yếu đến chuỗi tin cậy dựa trên hash của commit đã “Verified”: kẻ tấn công có thể tạo hash mới mà vẫn giữ chữ ký hợp lệ. Điểm then chốt là signature malleability làm hash không còn là định danh duy nhất cho nội dung.
Rủi ro vận hành nằm ở việc blocklist/provenance theo hash có thể bỏ sót các biến thể hash mới, ảnh hưởng quy trình kiểm duyệt và truy vết. Mức độ ảnh hưởng phụ thuộc vào việc tổ chức có pin theo hash commit hay có đối chiếu thêm hash độc lập của artifact hay không.
Một nghiên cứu chỉ ra rằng commit Git đã được ký có thể vẫn được GitHub gắn nhãn “Verified” ngay cả khi nội dung commit (tệp, tác giả, thời điểm) được giữ nguyên nhưng chữ ký bị signature malleability để tạo ra hash khác. Theo bài báo, kẻ tấn công có thể tạo “bản sao” commit với hash mới mà không cần khóa ký, khiến nhiều hệ thống coi hash của commit đã ký là định danh duy nhất.
Hệ quả trọng tâm là các cơ chế dựa trên hash như hash-based blocklists, provenance logs và dữ liệu reproducible-build có thể bị “lách” bằng cách đẩy lại cùng nội dung dưới hash chưa từng bị chặn. Ngoài ra, mirror hoặc nguồn phân phối không tin cậy có thể cung cấp các commit được ký hợp lệ nhưng hash khác với bản trên forge chính.
Nghiên cứu nhấn mạnh đây không phải hash collision: SHA-1/SHA-256 không bị phá vỡ. Vấn đề nằm ở việc forge tin vào hash commit khi chưa canonicalize chữ ký trước khi kiểm tra. Khuyến nghị: các hệ thống ghi nhận/đối chiếu theo hash nên xác minh và chuẩn hóa chữ ký trước khi tin vào hash; đồng thời ưu tiên kiểm soát theo hash độc lập của nội dung khi có thể.