Lỗ hổng TARmageddon trong thư viện async-tar Rust có thể dẫn đến thực thi mã từ xa

Các nhà nghiên cứu an ninh mạng đã công bố chi tiết về một lỗ hổng nghiêm trọng ảnh hưởng đến thư viện async-tar Rust phổ biến và các phiên bản fork của nó, bao gồm tokio-tar, có thể dẫn đến thực thi mã từ xa trong một số điều kiện nhất định. Lỗ hổng, được theo dõi với mã CVE-2025-62518 (điểm CVSS: 8.1), được Edera đặt tên là TARmageddon, và được phát hiện vào cuối tháng 8 năm 2025. Nó ảnh hưởng đến một số dự án được sử dụng rộng rãi.
Hình minh họa lỗ hổng TARmageddon trong các kho lưu trữ
Minh họa lỗ hổng TARmageddon

Các nhà nghiên cứu an ninh mạng đã công bố chi tiết về một lỗ hổng nghiêm trọng ảnh hưởng đến thư viện async-tar Rust phổ biến và các phiên bản fork của nó, bao gồm tokio-tar, có thể dẫn đến thực thi mã từ xa (RCE) trong một số điều kiện nhất định.

Lỗ hổng, được theo dõi với mã CVE-2025-62518 (điểm CVSS: 8.1), đã được Edera đặt tên là TARmageddon, công ty đã phát hiện ra vấn đề này vào cuối tháng 8 năm 2025. Nó ảnh hưởng đến một số dự án được sử dụng rộng rãi, như testcontainers và wasmCloud.

"Trong trường hợp xấu nhất, lỗ hổng này có mức độ nghiêm trọng 8.1 (Cao) và có thể dẫn đến thực thi mã từ xa (RCE) thông qua các cuộc tấn công ghi đè tệp, chẳng hạn như thay thế tệp cấu hình hoặc chiếm quyền kiểm soát các build backends," công ty bảo mật Edera có trụ sở tại Seattle cho biết.

Vấn đề càng trở nên trầm trọng hơn bởi thực tế rằng tokio-tar về cơ bản là phần mềm bị bỏ rơi (abandonware) dù thu hút hàng nghìn lượt tải xuống qua crates.io. Tokio-tar là một thư viện Rust để đọc và ghi các kho lưu trữ TAR bất đồng bộ, được xây dựng trên Tokio runtime cho ngôn ngữ lập trình này. crate của Rust này đã được cập nhật lần cuối vào ngày 15 tháng 7 năm 2023.

Trong trường hợp không có bản vá cho tokio-tar, người dùng dựa vào thư viện này được khuyến nghị chuyển sang astral-tokio-tar, phiên bản đã phát hành phiên bản 0.5.6 để khắc phục lỗ hổng.

"Các phiên bản astral-tokio-tar trước 0.5.6 chứa một lỗ hổng phân tích ranh giới cho phép kẻ tấn công đưa thêm các mục nhập kho lưu trữ bằng cách khai thác việc xử lý PAX/ustar header không nhất quán," nhà phát triển Astral William Woodruff cho biết trong một cảnh báo.
"Khi xử lý các kho lưu trữ với các PAX-extended headers chứa thông tin ghi đè kích thước, bộ phân tích cú pháp (parser) tiến sai vị trí luồng dựa trên ustar header size (thường là 0) thay vì kích thước được chỉ định bởi PAX, khiến nó diễn giải nội dung tệp là các TAR headers hợp lệ."

Vấn đề, nói tóm lại, là kết quả của việc xử lý không nhất quán khi xử lý các PAX extended headers và ustar headers trong việc xác định ranh giới dữ liệu tệp. PAX, viết tắt của portable archive interchange, là một phiên bản mở rộng của định dạng USTAR được sử dụng để lưu trữ các thuộc tính của các tệp thành viên trong một kho lưu trữ TAR.

Sự không khớp giữa PAX extended headers và ustar headers – trong đó PAX header chỉ định đúng kích thước tệp, trong khi ustar header chỉ định sai kích thước tệp là 0 (thay vì kích thước PAX) – dẫn đến sự không nhất quán trong phân tích cú pháp, khiến thư viện diễn giải nội dung bên trong như các mục nhập kho lưu trữ bên ngoài bổ sung.

"Bằng cách tiến 0 byte, bộ phân tích cú pháp không bỏ qua dữ liệu tệp thực tế (mà là một kho lưu trữ TAR lồng nhau) và ngay lập tức gặp TAR header hợp lệ tiếp theo nằm ở đầu kho lưu trữ lồng nhau," Edera giải thích. "Sau đó, nó diễn giải sai các headers của kho lưu trữ bên trong là các mục nhập hợp lệ thuộc về kho lưu trữ bên ngoài."

Kết quả là, kẻ tấn công có thể khai thác hành vi này để "buôn lậu" thêm các kho lưu trữ khi thư viện đang xử lý các tệp TAR lồng nhau, từ đó có thể ghi đè các tệp trong các thư mục giải nén, cuối cùng mở đường cho việc thực thi mã tùy ý.

Trong một kịch bản tấn công giả định, kẻ tấn công có thể tải lên một gói được tạo đặc biệt lên PyPI sao cho TAR bên ngoài chứa một pyproject.toml hợp pháp, trong khi TAR bên trong bị ẩn chứa một tệp độc hại chiếm quyền kiểm soát build backend và ghi đè tệp thực tế trong quá trình cài đặt.

"Mặc dù các đảm bảo của Rust khiến việc đưa vào các lỗi memory safety (như buffer overflows hoặc use-after-free) khó hơn đáng kể, nhưng nó không loại bỏ các logic bugs – và sự không nhất quán trong phân tích cú pháp này về cơ bản là một logic flaw," Edera cho biết. "Các nhà phát triển phải luôn cảnh giác với tất cả các loại lỗ hổng, bất kể ngôn ngữ được sử dụng."