Lỗ hổng Carriage Return và RCE khi clone trong Git

 (dgl.cx)
1 điểm bởi GN⁺ 2025-07-09 | Chưa có bình luận nào. | Chia sẻ qua WhatsApp
  • Trên các hệ Unix, nếu sao chép một kho lưu trữ không đáng tin bằng git clone --recursive, có thể dẫn tới thực thi mã từ xa qua CVE-2025-48384, vì vậy cần cập nhật Git và các phần mềm tích hợp Git
  • Nguyên nhân là do cách xử lý carriage return (\r) khác nhau giữa quá trình đọc và ghi lại cấu hình Git, khiến giá trị đã được kiểm tra khác với giá trị thực sự được sử dụng
  • Nếu thêm \r vào cuối path của submodule trong .gitmodules, đường dẫn checkout có thể bị đổi thành một đường dẫn khác sau khi kiểm tra
  • Windows không trực tiếp bị ảnh hưởng vì không cho phép ký tự điều khiển trong tên tệp, nhưng macOS bị ảnh hưởng bởi cả CVE-2024-32002 và CVE-2025-48384
  • Bản vá thay đổi để bọc các giá trị cấu hình chứa \r trong dấu ngoặc kép, chặn các đường tấn công như ghi tệp bên trong .git và tạo Git hook

Tổng quan lỗ hổng và hành động cần làm ngay

  • CVE-2025-48384 là lỗ hổng Git có thể dẫn đến thực thi mã từ xa khi sao chép một kho lưu trữ không đáng tin bằng git clone --recursive trên các nền tảng Unix
  • Cần cập nhật lên phiên bản Git đã được vá và đồng thời cập nhật các phần mềm có tích hợp Git, bao gồm cả GitHub Desktop
  • Nếu chỉ chạy git clone trên dòng lệnh thì submodule sẽ không tự động được sao chép
    • Một cách giảm thiểu là trước tiên chạy git clone mà không có --recursive, kiểm tra .gitmodules có an toàn hay không rồi mới khởi tạo submodule
  • GitHub Desktop mặc định sao chép với tùy chọn đệ quy nên có thể bị ảnh hưởng trong hành vi này

Carriage return và tệp cấu hình Git

  • Carriage return là ký tự ASCII số 13, tức Carriage Return, và được biểu diễn là \r trong chuỗi C
  • Unix dự định chỉ dùng LF, tức \n, để ngắt dòng, nhưng Windows và nhiều giao thức Internet lại dùng CR+LF, tức \r\n
  • Định dạng cấu hình kiểu .ini của Git không chỉ được dùng cho tệp cấu hình người dùng mà còn cho cả tệp .gitmodules nằm trong kho lưu trữ
  • Trình phân tích cấu hình của Git hỗ trợ kết thúc dòng kiểu DOS nên hoạt động như sau khi đọc ký tự
    • Nếu ký tự hiện tại là \r thì kiểm tra ký tự tiếp theo
    • Nếu ký tự tiếp theo là \n thì bỏ \r và xử lý như xuống dòng
    • Nếu ký tự tiếp theo không phải \n thì trả ký tự đó lại và tự trả về \r
  • Cách xử lý này được áp dụng theo từng dòng, nên nếu một dòng kết thúc bằng CR thì CR đó có thể bị loại bỏ bất kể định dạng chung của toàn bộ tệp là gì

Sự không nhất quán giữa đọc và ghi

  • Git không chỉ đọc tệp cấu hình mà còn ghi các cặp key = value khi ghi giá trị cấu hình, chẳng hạn như git config
  • Mã cũ chỉ bọc giá trị trong dấu ngoặc kép khi ghi lại cấu hình trong các trường hợp sau
    • Giá trị bắt đầu bằng khoảng trắng
    • Giá trị chứa ; hoặc #
    • Giá trị kết thúc bằng khoảng trắng
  • Trong khi đó, mã đọc cấu hình hỗ trợ chuỗi có dấu ngoặc kép, nên khi giá trị do write_pair ghi ra được đọc lại sau này, ký tự \r cuối cùng có thể bị rơi mất
  • Ví dụ, nếu tệp cấu hình có key = "foo^M" thì sau khi ghi lại có thể biến thành key = foo^M
    • Ở đây ^M là ký tự CR theo nghĩa đen
  • Khi hành vi này kết hợp với giá trị .gitmodules không đáng tin, việc xử lý đường dẫn submodule sẽ bị xáo trộn

Nhầm lẫn đường dẫn submodule và phạm vi ảnh hưởng

  • Trên các hệ thống Unix, có thể đưa ký tự điều khiển vào tên tệp nên có thể đặt giá trị path trong .gitmodules chứa CR
  • Ví dụ có dạng như sau
[submodule "foo"]
  path = "foo^M"
  • Khi giá trị này được mã cấu hình Git ghi vào .git/modules/foo/config, nó có thể trở thành dạng sau
[core]
  workdir = ../../../foo^M
  • Việc kiểm tra đã hoàn tất từ trước đối với đường dẫn không đáng tin được đọc từ .gitmodules
  • Sau đó, trong quá trình đọc lại cấu hình, nếu \r cuối bị loại bỏ, Git sẽ dùng một đường dẫn khác với đường dẫn đã được kiểm tra
  • Kết quả là trong lúc sao chép submodule, vị trí đọc từ path = ... có thể khác với vị trí thực sự được ghi và sử dụng
  • Nguyên lý này tương tự CVE-2024-32002
    • CVE-2024-32002 làm Git nhầm lẫn bằng cách lợi dụng việc hệ thống có phân biệt chữ hoa chữ thường hay không trong submodule
    • CVE-2025-48384 yêu cầu hệ thống tệp cho phép ký tự điều khiển trong tên tệp
  • Windows không cho phép ký tự điều khiển trong tên tệp nên không trực tiếp bị ảnh hưởng bởi lỗi cụ thể này
  • macOS bị ảnh hưởng bởi cả CVE-2024-32002 và CVE-2025-48384

Bản vá và khả năng khai thác

  • Bản vá thay đổi write_pair để nếu giá trị chứa \r thì chuỗi sẽ được bọc trong dấu ngoặc kép
  • Thay đổi này chỉ đơn giản là thêm '\r' vào điều kiện vốn trước đây chỉ kiểm tra ; hoặc #
 	for (i = 0; value[i]; i++)
-		if (value[i] == ';' || value[i] == '#')
+		if (value[i] == ';' || value[i] == '#' || value[i] == '\r')
 			quote = "\"";
  • Sự nhầm lẫn đường dẫn cho phép đặt các tệp độc hại của submodule vào gần như vị trí tùy ý trên hệ thống tệp, và do đã vượt qua kiểm tra nên còn có thể đi theo các symbolic link nằm ngoài kho lưu trữ
  • Cách khai thác trực tiếp nhất là ghi tệp vào bên trong thư mục .git và tạo Git hook script, từ đó khi Git chạy hook thì mã do kẻ tấn công kiểm soát sẽ được thực thi
  • Một khả năng khác là ghi đè .git/config
  • Dù PoC vẫn chưa được công bố, tác giả cho biết chỉ cần sửa gần như rất nhỏ từ exploit của CVE-2024-32002 là được
  • Bài kiểm thử trong commit sửa lỗi có thể cung cấp nhiều gợi ý về cách tấn công

Vấn đề CR lặp lại và bài học rút ra

  • Đây không phải lần đầu carriage return gây ra vấn đề cho Git
  • Vào tháng 1, RyotaK đã phát hiện một vấn đề trong giao thức credential helper có thể bị đánh lừa bằng carriage return
  • Năm 2023, André Baptista và Vítor Pinho đã phát hiện CVE-2023-29007, một lỗi logic trong phân tích cấu hình
  • Lỗ hổng này không phải vấn đề riêng của ngôn ngữ C mà gần hơn với một lỗi logic có thể xảy ra trong hầu như mọi ngôn ngữ
  • Điểm chung là chúng xảy ra trong giao tiếp liên tiến trình giữa các thành phần nội bộ của Git hoặc giữa Git với tiến trình bên ngoài
  • Có thể thấy cấu trúc tương tự với CRLF injection, request smuggling và SMTP smuggling trong HTTP
  • Internet trước đây dựa vào nguyên tắc độ bền của Postel: “hãy nghiêm ngặt khi gửi, và khoan dung khi nhận”, nhưng ngày nay đó có thể không còn là lời khuyên hợp lý nhất
  • Chủ đề này được bàn chi tiết hơn trong RFC 9413

Lời cảm ơn và các bản sửa liên quan

Bài viết liên quan

Chưa có bình luận nào.

Chưa có bình luận nào.