-
09/04/2020
-
123
-
1.405 bài viết
Lỗ hổng nghiêm trọng trong lz4-java có thể dẫn tới rò rỉ dữ liệu
Một lỗ hổng nghiêm trọng vừa được phát hiện trong thư viện lz4-java, vốn được sử dụng rộng rãi trong nhiều hệ thống Java để xử lý nén và giải nén tốc độ cao. Lỗ hổng này mang mã CVE-2025-66566 với điểm CVSS 8.2, cho thấy mức rủi ro lớn đối với an toàn dữ liệu. Điều gây lo ngại nằm ở chỗ bộ giải nén có khả năng để lộ vùng nhớ chưa được khởi tạo, nơi này thường chứa lại dữ liệu từ những tác vụ trước đó và đôi khi bao gồm cả thông tin nhạy cảm.
Vấn đề bắt nguồn từ cách thư viện quản lý bộ đệm đầu ra. Khi dữ liệu được giải nén, buffer đầu ra lẽ ra cần được làm sạch nhưng thực tế lại không được xoá trước khi sử dụng. Từ đây, một gói dữ liệu được chuẩn bị có chủ đích có thể khiến bộ giải nén sao chép nội dung từ những vùng chưa hề chứa kết quả giải nén. Nếu ứng dụng đang tái sử dụng bộ đệm nhằm tiết kiệm tài nguyên, vùng bộ nhớ còn sót lại có thể chứa mật khẩu, khoá mã hoá hoặc dữ liệu người dùng. Khi nội dung này vô tình được đưa vào kết quả giải nén, dữ liệu nhạy cảm sẽ bị lộ ra ngoài mà không để lại dấu hiệu bất thường.
Mặc dù vậy, không phải các bản triển khai của lz4-java đều bị ảnh hưởng. Những phiên bản dùng mã native thông qua JNI vẫn an toàn, nhưng việc một ứng dụng có bị tác động hay không lại phụ thuộc vào cách lập trình viên lựa chọn công cụ giải nén. Nhiều lựa chọn quen thuộc như safeInstance() và unsafeInstance() thực chất dựa trên triển khai Java thuần, vì vậy dễ gặp rủi ro. Thêm vào đó, fastestInstance() thường được nhiều người mặc định là sử dụng mã native, nhưng trong trường hợp môi trường không hỗ trợ JNI, nó sẽ âm thầm quay về phiên bản Java thuần. Ngay cả bộ giải nén được cho là nhanh nhất trong nativeInstance() cũng chịu ảnh hưởng do kế thừa lại logic không an toàn từ những phiên bản trước.
Mức độ nghiêm trọng của CVE-2025-66566 ngoài thực tế lại phụ thuộc trực tiếp vào cách ứng dụng quản lý bộ nhớ. Những hệ thống luôn tạo buffer mới hoặc chỉ dùng các vùng nhớ đã được làm sạch gần như miễn nhiễm với rủi ro. Tuy nhiên, các nền tảng xử lý lưu lượng lớn, dịch vụ streaming hay môi trường nhiều phiên làm việc liên tục thường ưu tiên tái sử dụng bộ nhớ để tối ưu hiệu năng. Chính tại đây, nguy cơ bắt đầu lộ rõ. Vùng nhớ cũ có thể âm thầm mang theo dữ liệu nhạy cảm và khi được sao chép vào kết quả giải nén, toàn bộ thông tin bị rò rỉ theo cách gần như không để lại dấu vết. Điều này khiến việc phát hiện sự cố trở nên vô cùng khó khăn dù hệ thống vẫn vận hành bình thường.
Nhóm phát triển đã phát hành bản vá trong lz4-java 1.10.1 và đây là lựa chọn an toàn nhất ở thời điểm hiện tại. Việc cập nhật sớm được khuyến nghị mạnh mẽ để loại bỏ hoàn toàn nguy cơ rò rỉ vùng nhớ chưa được khởi tạo. Nếu hệ thống chưa thể nâng cấp ngay, giải pháp tạm thời là làm sạch toàn bộ bộ đệm đầu ra trước khi giải nén. Cách này có thể làm tăng thời gian xử lý, nhưng vẫn đủ để ngăn dữ liệu cũ xuất hiện trong kết quả giải nén và giảm thiểu rủi ro lộ thông tin.
Vấn đề bắt nguồn từ cách thư viện quản lý bộ đệm đầu ra. Khi dữ liệu được giải nén, buffer đầu ra lẽ ra cần được làm sạch nhưng thực tế lại không được xoá trước khi sử dụng. Từ đây, một gói dữ liệu được chuẩn bị có chủ đích có thể khiến bộ giải nén sao chép nội dung từ những vùng chưa hề chứa kết quả giải nén. Nếu ứng dụng đang tái sử dụng bộ đệm nhằm tiết kiệm tài nguyên, vùng bộ nhớ còn sót lại có thể chứa mật khẩu, khoá mã hoá hoặc dữ liệu người dùng. Khi nội dung này vô tình được đưa vào kết quả giải nén, dữ liệu nhạy cảm sẽ bị lộ ra ngoài mà không để lại dấu hiệu bất thường.
Mặc dù vậy, không phải các bản triển khai của lz4-java đều bị ảnh hưởng. Những phiên bản dùng mã native thông qua JNI vẫn an toàn, nhưng việc một ứng dụng có bị tác động hay không lại phụ thuộc vào cách lập trình viên lựa chọn công cụ giải nén. Nhiều lựa chọn quen thuộc như safeInstance() và unsafeInstance() thực chất dựa trên triển khai Java thuần, vì vậy dễ gặp rủi ro. Thêm vào đó, fastestInstance() thường được nhiều người mặc định là sử dụng mã native, nhưng trong trường hợp môi trường không hỗ trợ JNI, nó sẽ âm thầm quay về phiên bản Java thuần. Ngay cả bộ giải nén được cho là nhanh nhất trong nativeInstance() cũng chịu ảnh hưởng do kế thừa lại logic không an toàn từ những phiên bản trước.
Mức độ nghiêm trọng của CVE-2025-66566 ngoài thực tế lại phụ thuộc trực tiếp vào cách ứng dụng quản lý bộ nhớ. Những hệ thống luôn tạo buffer mới hoặc chỉ dùng các vùng nhớ đã được làm sạch gần như miễn nhiễm với rủi ro. Tuy nhiên, các nền tảng xử lý lưu lượng lớn, dịch vụ streaming hay môi trường nhiều phiên làm việc liên tục thường ưu tiên tái sử dụng bộ nhớ để tối ưu hiệu năng. Chính tại đây, nguy cơ bắt đầu lộ rõ. Vùng nhớ cũ có thể âm thầm mang theo dữ liệu nhạy cảm và khi được sao chép vào kết quả giải nén, toàn bộ thông tin bị rò rỉ theo cách gần như không để lại dấu vết. Điều này khiến việc phát hiện sự cố trở nên vô cùng khó khăn dù hệ thống vẫn vận hành bình thường.
Nhóm phát triển đã phát hành bản vá trong lz4-java 1.10.1 và đây là lựa chọn an toàn nhất ở thời điểm hiện tại. Việc cập nhật sớm được khuyến nghị mạnh mẽ để loại bỏ hoàn toàn nguy cơ rò rỉ vùng nhớ chưa được khởi tạo. Nếu hệ thống chưa thể nâng cấp ngay, giải pháp tạm thời là làm sạch toàn bộ bộ đệm đầu ra trước khi giải nén. Cách này có thể làm tăng thời gian xử lý, nhưng vẫn đủ để ngăn dữ liệu cũ xuất hiện trong kết quả giải nén và giảm thiểu rủi ro lộ thông tin.
Theo Security Online
Chỉnh sửa lần cuối: