Lỗi deserialization trong WordPress WP_HTML_Token cho phép thực thi mã

WordPress là một nền tảng xuất bản mở cho Web. Việc unserialization các instance của lớp WP_HTML_Token cho phép thực thi mã thông qua magic method __destruct() của lớp này. Vấn đề này đã được khắc phục trong WordPress 6.4.2 vào ngày 6 tháng 12 năm 2023. Các phiên bản trước 6.4.0 không bị ảnh hưởng.

WordPress là sản phẩm bị ảnh hưởng; normalized record xác định package là wordpress-develop.

• Các bản WordPress >= 6.4.0 < 6.4.2 được xác nhận là affected.
• Các bản WordPress trước 6.4.0 được advisory của CNA xác định là không bị ảnh hưởng.
• WordPress 6.4.2 là bản patched được xác nhận.
• Bằng chứng hiện có không đủ để khẳng định trạng thái của mọi release branch khác ngoài các boundary nêu trên. Không nên suy ra rằng mọi bản cao hơn hoặc mọi branch song song đều đã được xác minh chỉ từ việc một bản sửa lỗi tồn tại.

WordPress thực hiện unserialization các instance của lớp WP_HTML_Token; magic method __destruct() của lớp này có thể dẫn đến thực thi mã. Đây là lỗi CWE-502: Deserialization of Untrusted Data, trong đó dữ liệu serialized không đáng tin cậy được xử lý theo cách cho phép kích hoạt hành vi nguy hiểm của object. Hồ sơ xác định đường tấn công có thể đạt qua mạng, nhưng không nêu endpoint, trường request, parser entry point hoặc nguồn serialized data cụ thể. Các đánh giá hiện có thống nhất rằng attack complexity thấp và không cần user interaction, nhưng không thống nhất về yêu cầu privilege: advisory của CNA ghi nhận high privileges, trong khi đánh giá của NVD ghi nhận không cần privilege. Chi tiết implementation đã thay đổi để khắc phục trong bản sửa lỗi không được công bố trong bằng chứng hiện có.

• Đường tấn công được mô tả là qua network, với attack complexity thấp và không cần user interaction.
• Advisory của vendor/CNA mô hình hóa yêu cầu privilege cao; đánh giá NVD lại mô hình hóa trường hợp không cần privilege. Vì vậy, cần xác minh request path và quyền thực tế của deployment thay vì giả định một trong hai mô hình là đúng cho mọi hệ thống.
• Advisory cho biết lỗ hổng đã được công bố công khai như một zero-day, nhưng hồ sơ được cung cấp không xác nhận exploitation trong thực tế. Trường known_exploited là null và public_exploit được đánh dấu false; điều này không chứng minh rằng chưa từng có khai thác.
• Kết quả nghiên cứu có một repository GitHub tự nhận chứa exploit module, nhưng nội dung có các dấu hiệu không đáng tin cậy và không xác nhận được exploit hoạt động cho record này. Không nên dùng repository đó làm bằng chứng thay thế cho advisory của vendor.

Kết quả kỹ thuật được xác nhận là code execution thông qua quá trình unserialization của WP_HTML_Token và magic method __destruct(). Tùy quyền của WordPress hoặc PHP process, môi trường isolation và các secret mà process có thể truy cập, việc này có thể dẫn đến thay đổi site, đọc dữ liệu hoặc gây gián đoạn dịch vụ.

Advisory của vendor/CNA mô hình hóa tác động confidentiality và integrity ở mức hạn chế, không ghi nhận availability impact, đồng thời yêu cầu privilege cao. Đánh giá NVD mô hình hóa trường hợp không cần privilege với tác động cao hơn trên confidentiality, integrity và availability. Mâu thuẫn này chưa được giải thích trong mô tả kỹ thuật, nên không nên mặc định rằng lỗ hổng luôn yêu cầu đăng nhập hoặc luôn có thể bị khai thác ẩn danh.

Phạm vi mà code execution có thể vượt ra ngoài security boundary của WordPress cũng phụ thuộc vào quyền process và isolation của host; hồ sơ không cung cấp đủ chi tiết để khẳng định điều đó.

Lỗi được mô tả là có thể dẫn đến thực thi mã trong tiến trình WordPress. Nếu bị kích hoạt thành công, hậu quả có thể gồm thay đổi trái phép nội dung hoặc configuration của site, truy cập dữ liệu và secret mà web process có quyền đọc, hoặc gián đoạn dịch vụ; đây là các khả năng phụ thuộc vào quyền của process và cách ly deployment, không phải bằng chứng về một breach cụ thể.

Do advisory của vendor/CNA và đánh giá NVD sử dụng các giả định khác nhau về privilege và mức độ ảnh hưởng, mức độ phơi nhiễm thực tế cần được xác minh theo kiến trúc và request path của từng hệ thống. Không có nạn nhân, chiến dịch, breach hoặc indicator cụ thể nào được xác định trong bằng chứng hiện có.

1. Nâng cấp các installation thuộc affected range lên WordPress 6.4.2, là bản fixed đã được xác nhận bởi advisory.
2. Nếu chưa thể cập nhật ngay, coi hệ thống là có nguy cơ và áp dụng các compensating control đã được kiểm chứng riêng cho deployment. Bằng chứng hiện có không cung cấp temporary mitigation hoặc endpoint-specific workaround đáng tin cậy.
3. Sau khi cập nhật, xác minh version của WordPress đang thực sự được web server và runtime sử dụng, đồng thời kiểm tra các instance, image hoặc source tree cũ có thể vẫn được phục vụ.
4. Rà soát quyền của web process và các đường xử lý serialized data trong ứng dụng để giảm tác động nếu có request độc hại, nhưng không coi đây là biện pháp thay thế cho bản cập nhật đã xác nhận.

1. Lập inventory toàn bộ WordPress core deployment và đối chiếu version đang chạy với affected range và fixed boundary trong mục affected_summary.
2. Xác nhận version của runtime thực tế, không chỉ version trong source tree, image tag hoặc package metadata. Kiểm tra các bản sao WordPress trong web root, container image và môi trường staging nếu chúng có thể được đưa vào production.
3. Rà soát application và web-server telemetry để tìm các request đã đi tới code path thực hiện unserialization object WordPress. Advisory không cung cấp endpoint, request field hay log signature cụ thể, vì vậy đây chỉ là biện pháp rà soát thận trọng, không phải IOC đã được xác nhận.
4. Sau khi xác định hệ thống có thể đã exposed, kiểm tra thay đổi bất thường đối với nội dung, configuration, administrative accounts, file và hoạt động của process. Đây là các dấu hiệu điều tra chung, không phải indicator riêng của lỗ hổng này.
5. Không xem việc không có log đáng ngờ là bằng chứng hệ thống an toàn. Patch status và version inventory vẫn là phép kiểm tra quyết định.