Tràn số trong bộ phân tích TAR của PHP Group PHP cho phép chèn entry archive

phar_tar_number() phân tích trường kích thước dạng bát phân của một TAR header vào uint32_t nhưng không kiểm tra tràn số. Trường này rộng 11 chữ số bát phân và chứa các giá trị đến 0x1FFFFFFFF, vì vậy kích thước lớn hơn 0xFFFFFFFF sẽ âm thầm bị wrap. Sau đó parser bỏ qua sai số data block và diễn giải nội dung file do attacker kiểm soát như TAR header tiếp theo, cho phép một archive được tạo đặc biệt chèn các entry mà PharData báo cáo và giải nén như thể chúng là dữ liệu thật.

PHP Group PHP có default status là unaffected ngoài các nhánh được liệt kê trong bản ghi. Các phạm vi bị ảnh hưởng và bản sửa tương ứng là:

• Nhánh 8.2.*: affected khi nhỏ hơn 8.2.34; bản sửa được nêu là 8.2.34.
• Nhánh 8.3.*: affected khi nhỏ hơn 8.3.35; bản sửa được nêu là 8.3.35.
• Nhánh 8.4.*: affected khi nhỏ hơn 8.4.26; bản sửa được nêu là 8.4.26.
• Nhánh 8.5.*: affected khi nhỏ hơn 8.5.11; bản sửa được nêu là 8.5.11.

Không nên suy ra trạng thái của các nhánh hoặc bản phân phối khác chỉ từ các mốc trên; cần đối chiếu advisory của nhà cung cấp và gói PHP thực tế đang triển khai.

Hàm phar_tar_number() đọc trường kích thước dạng bát phân của TAR vào kiểu uint32_t nhưng không kiểm tra tràn số. Trường này rộng 11 chữ số bát phân và có thể biểu diễn giá trị đến 0x1FFFFFFFF; vì vậy giá trị lớn hơn 0xFFFFFFFF bị wrap im lặng. Kích thước bị wrap làm parser bỏ qua sai số block dữ liệu, sau đó diễn giải nội dung do attacker kiểm soát như TAR header tiếp theo. Khi ứng dụng sử dụng PharData hoặc stream wrapper phar:// để mở archive không tin cậy, các entry được chèn có thể xuất hiện như entry hợp lệ và được extractTo() ghi ra đĩa. Advisory của PHP cho biết bản sửa đổi cơ chế đọc kích thước sang uint64_t, từ chối các giá trị không hợp lệ và xử lý việc bỏ qua block dữ liệu theo loại entry. Chi tiết về cách một ứng dụng cụ thể phân quyền hoặc sử dụng các file được giải nén không được xác định trong bằng chứng hiện có.

Bản ghi phân loại khả năng khai thác là local, độ phức tạp thấp, không yêu cầu authentication và không yêu cầu user interaction. Điều kiện cần là ứng dụng hoặc công cụ phải xử lý TAR hoặc TAR.GZ được tạo đặc biệt qua PharData hoặc phar://; bằng chứng không tự nó chứng minh một đường khai thác qua mạng từ xa. Bản ghi đánh dấu public exploit là true, và dữ liệu enrichment chỉ ra đã có proof of concept. Bằng chứng được cung cấp không nêu một chiến dịch đang hoạt động, nạn nhân cụ thể hoặc việc khai thác ngoài thực tế.

Khi parser xử lý trường kích thước vượt giới hạn của uint32_t, giá trị bị wrap và ranh giới giữa các block TAR bị tính sai. Nội dung file do attacker kiểm soát có thể được đọc như header mới, làm PharData báo cáo các entry giả và extractTo() ghi chúng ra đĩa. Đây là tác động đến tính toàn vẹn của archive và các file được giải nén, có thể ảnh hưởng đến thư mục dependency hoặc thư mục đầu ra của ứng dụng. Bản ghi không xác định quyền cao hơn, rò rỉ thông tin hoặc denial of service là kết quả của lỗi này. Mức độ thực tế phụ thuộc vào việc ứng dụng có xử lý archive không tin cậy hay không và process giải nén có quyền ghi ở đâu.

Lỗi có thể làm sai lệch kết quả kiểm tra archive và nội dung thực tế được ghi ra thư mục đích, tạo rủi ro về tính toàn vẹn của dữ liệu và artefact phần mềm.

• Ứng dụng dùng PharData hoặc phar:// có thể nhìn thấy các entry không phản ánh đúng cấu trúc archive ban đầu.
• extractTo() có thể ghi các entry được chèn vào đĩa, khiến bước xác thực trước đó kiểm tra một tập file còn bước giải nén tạo ra tập file khác.
• Trong luồng Composer TarDownloader, package TAR.GZ được xử lý bằng PharData rồi giải nén vào vendor/, nên package được tạo đặc biệt có thể đưa file vào vị trí này.
• Hậu quả tiếp theo phụ thuộc vào file bị ghi và cách ứng dụng sử dụng chúng; bằng chứng hiện có không xác nhận rò rỉ dữ liệu hoặc mất tính sẵn sàng.

1. Nâng cấp theo đúng nhánh đang sử dụng: cập nhật nhánh 8.2.* lên 8.2.34, nhánh 8.3.* lên 8.3.35, nhánh 8.4.* lên 8.4.26, hoặc nhánh 8.5.* lên 8.5.11.
2. Kiểm tra lại package PHP thực tế sau khi cập nhật để bảo đảm thành phần ext-phar đã nhận bản sửa, thay vì chỉ thay đổi một binary hoặc image không được workload sử dụng.
3. Cho đến khi cập nhật xong, tránh đưa TAR hoặc TAR.GZ không tin cậy vào các luồng dùng PharData, phar:// hoặc Composer TarDownloader nếu quy trình cho phép.
4. Tăng cường kiểm tra độc lập manifest và nội dung archive trước khi giải nén. Đây là biện pháp giảm rủi ro tạm thời, không thay thế bản sửa của nhà cung cấp.
5. Không diễn giải một mốc fixed của một nhánh thành phạm vi mở cho mọi nhánh khác; các nhánh ngoài danh sách cần được xác minh riêng.

1. Kiểm kê các máy chủ và job đang chạy PHP, xác định những cài đặt có ext-phar và những workload sử dụng PharData, phar:// hoặc Composer TarDownloader.
2. Đối chiếu các phiên bản PHP trong inventory với các nhánh bị ảnh hưởng và bản sửa tương ứng được nêu trong affected_summary.
3. Rà soát quy trình nhận và giải nén TAR hoặc TAR.GZ, đặc biệt các luồng kiểm tra manifest trước rồi mới gọi extractTo().
4. Kiểm tra log ứng dụng và package manager để tìm các archive không tin cậy được xử lý, cùng các file bất ngờ xuất hiện trong thư mục đích như vendor/. Đây là tín hiệu cần điều tra, không phải IOC được vendor xác nhận.
5. Khi có thể, so sánh danh sách entry do PharData nhìn thấy với kết quả của một TAR parser độc lập. Sự khác biệt là dấu hiệu rà soát, nhưng việc không thấy khác biệt không chứng minh hệ thống an toàn.