Cảnh báo: Commit ‘Verified’ trên GitHub có thể bị thay đổi hash mà không làm hỏng chữ ký

Một nghiên cứu mới từ Jacob Ginesin, nghiên cứu sinh tại Đại học Carnegie Mellon và chuyên gia kiểm định mật mã tại Cure53, đã hé lộ một lỗ hổng thú vị liên quan đến cách GitHub xử lý các commit đã được ký số (signed commit). Cụ thể, kẻ tấn công có thể tạo ra các commit mới với cùng nội dung, tác giả và thời gian, nhưng có hash khác biệt mà vẫn được GitHub gắn nhãn “Verified”.

Hash chain malleability là gì?

Vấn đề nằm ở chỗ GitHub không thực hiện chuẩn hóa (normalize) chữ ký trước khi kiểm tra. Vì hash của một commit được tính toán dựa trên toàn bộ dữ liệu bên trong, bao gồm cả các byte chữ ký trong header, nên việc thay đổi các byte này (mà không làm mất hiệu lực chữ ký) sẽ tạo ra một hash hoàn toàn mới. Ginesin gọi hiện tượng này là “hash chain malleability”.

Nghiên cứu chỉ ra ba phương thức tấn công chính áp dụng cho các loại chữ ký mà GitHub hỗ trợ:

• ECDSA keys: Thay đổi giá trị chữ ký bằng cách sử dụng tính chất đối xứng của đường cong elliptic (chuyển giá trị s thành n – s).
• RSA và EdDSA keys: Chèn thêm các trường dữ liệu không được kiểm tra (unhashed section) vào chữ ký.
• S/MIME (X.509) keys: Tái cấu trúc trường độ dài trong cấu trúc DER của chữ ký sang định dạng không chuẩn.

Tại sao điều này lại nguy hiểm?

Mặc dù đây không phải là cách để chèn mã độc vào các tệp tin (vì nội dung tệp vẫn giữ nguyên), nhưng nó gây ra rủi ro lớn cho các hệ thống tự động hóa. Nếu một hệ thống bảo mật chặn các commit độc hại dựa trên hash, kẻ tấn công có thể dễ dàng “lách” qua bằng cách tạo ra một commit “sinh đôi” với hash mới mà hệ thống chưa từng ghi nhận vào danh sách chặn (blocklist).

GitHub hiện tại vẫn ghi nhận trạng thái “Verified” cho các commit này và không thực hiện kiểm tra lại ngay cả khi khóa ký đã bị thu hồi. Điều này tạo ra sự sai lệch trong các hệ thống theo dõi nguồn gốc (provenance logs) và các quy trình build tái lập (reproducible-build).

Khuyến nghị

Theo tác giả, đây không phải là lỗi của Git mà là vấn đề trong cách các nền tảng forge (như GitHub) xác thực chữ ký. Giải pháp triệt để là các nền tảng này cần thực hiện chuẩn hóa chữ ký trước khi xác thực hash. Đối với các nhà phát triển, lời khuyên vẫn không đổi: hãy tiếp tục sử dụng việc ghim (pin) commit hash để đảm bảo tính toàn vẹn của mã nguồn, nhưng cần hiểu rằng một chữ ký hợp lệ chỉ chứng minh ai là người ký, chứ không đảm bảo hash của commit đó là duy nhất và không thể thay đổi.

Nguồn tham khảo: The Hacker News