PHP Group PHP: lỗi hỏng trạng thái request do hết bộ nhớ cho phép thực thi mã từ xa

PHP sử dụng longjmp() cho các lỗi hết bộ nhớ (OOM) để thoát khỏi context hiện tại và hủy việc xử lý request. Một số context có thể không xử lý đúng tình huống này và để lại bộ nhớ của request ở trạng thái chưa được khởi tạo trước khi thực hiện một lần cấp phát. Quy trình dọn dẹp request tiếp theo có thể đọc hoặc rẽ nhánh dựa trên vùng nhớ này. Nhiều chiến lược OOM có thể kích hoạt một cách ổn định tình trạng này và dẫn đến thực thi mã từ xa (RCE).

• php-src thuộc PHP Group, nhánh PHP 8.2.*: affected khi version nhỏ hơn 8.2.35; fixed tại 8.2.35.
• php-src thuộc PHP Group, nhánh PHP 8.3.*: affected khi version nhỏ hơn 8.3.36; fixed tại 8.3.36.
• php-src thuộc PHP Group, nhánh PHP 8.4.*: affected khi version nhỏ hơn 8.4.27; fixed tại 8.4.27.
• php-src thuộc PHP Group, nhánh PHP 8.5.*: affected khi version nhỏ hơn 8.5.12; fixed tại 8.5.12.

Các boundary trên áp dụng cho những nhánh được ghi nhận trong affected-product record. Record không cung cấp boundary affected hoặc fixed upstream đầy đủ cho các nhánh khác, vì vậy trạng thái của PHP được vendor hoặc bản phân phối đóng gói riêng cần được xác minh bằng advisory và package tương ứng.

PHP sử dụng longjmp() để thoát khỏi context hiện tại khi xảy ra lỗi hết bộ nhớ. Trong một số context, vùng nhớ của request đã có thể được truy cập nhưng chưa được khởi tạo đầy đủ; nếu một lần cấp phát thất bại tại thời điểm này, đường thoát sớm không cập nhật đầy đủ trạng thái nội bộ và để lại trạng thái request không hợp lệ. Quy trình dọn dẹp request sau đó có thể đọc hoặc rẽ nhánh dựa trên vùng nhớ không hợp lệ, tạo điều kiện cho lỗi use-after-free hoặc truy cập con trỏ chưa khởi tạo.

1. Input do attacker kiểm soát có thể làm PHP đi vào trạng thái OOM trong quá trình xử lý request, đặc biệt khi phân tích multipart request.
2. Các điều kiện được advisory nêu gồm request multipart không có Content-Length hữu dụng, số lượng header không giới hạn trong một part, các file control rỗng không bị tính vào max_file_uploads, và tên field lồng nhau làm tăng đáng kể số lượng cấu trúc cần tạo.
3. Khi request startup thất bại dưới Apache mod_php, request shutdown vẫn được gọi trước khi mã ứng dụng chạy, nên trạng thái không hợp lệ có thể bị xử lý ngay trong PHP core.
4. FPM loại bỏ child khi request startup thất bại, nhưng vẫn có thể còn các đường đi OOM sau startup. Advisory xác nhận tính dễ bị ảnh hưởng của FPM qua phân tích mã, nhưng chưa xác nhận một khai thác hoàn chỉnh cho SAPI này.

Bản vá thay đổi cách xử lý OOM, loại bỏ việc dùng longjmp() trong đường đi này và trì hoãn soft OOM đến một VM safe point, đồng thời dùng hard OOM ở ngưỡng cao hơn. Chi tiết về bố trí allocator hoặc mọi điều kiện triển khai cần thiết để đạt độ tin cậy khai thác không được xác định đầy đủ trong dữ liệu được cung cấp.

Lỗ hổng có thể bị kích hoạt từ xa qua HTTP mà không cần xác thực hoặc tương tác của người dùng. Advisory của PHP xác nhận remote code execution hoàn chỉnh qua Apache mod_php, với cấu hình input và memory mặc định, trong mô hình prefork; việc xử lý có thể xảy ra trước khi mã ứng dụng bắt đầu chạy.

• Độ tin cậy khai thác phụ thuộc vào bản build PHP, extension, frontend, allocator và số lượng worker.
• Với PHP-FPM, việc child thoát khi OOM xảy ra trong request startup ngăn một đường khai thác cụ thể, nhưng các đường OOM sau startup vẫn có thể còn tồn tại. Chưa có khai thác FPM hoàn chỉnh được xác nhận trong advisory.
• FrankenPHP được đánh giá là có khả năng dễ bị ảnh hưởng tương tự mod_php; các triển khai LSAPI được đánh giá là có khả năng cần điều kiện gắn với ứng dụng nhưng chưa được xác thực.
• Evidence hiện có xác nhận việc kiểm thử khai thác qua HTTP, nhưng không xác định một nạn nhân, chiến dịch hoặc vụ xâm nhập cụ thể.

Kết quả kỹ thuật được xác nhận là remote code execution không cần xác thực với quyền của web worker. Với Apache mod_php, PHP có thể xử lý trạng thái request không hợp lệ trong request shutdown trước khi application code được thực thi, làm tăng phạm vi ảnh hưởng độc lập với logic của ứng dụng.

• Attacker có thể đạt tác động lên tính bí mật, toàn vẹn và sẵn sàng của hệ thống mà worker có quyền truy cập.
• OOM trong quá trình xử lý input có thể đồng thời gây lỗi request, loại bỏ worker hoặc làm gián đoạn dịch vụ.
• FPM có hành vi khác khi request startup thất bại và chưa có khai thác hoàn chỉnh được xác nhận cho SAPI này, nhưng advisory vẫn xem FPM là có khả năng bị ảnh hưởng bởi các đường OOM sau startup.
• Khai thác không tự động chứng minh được quyền hệ điều hành cao hơn, truy cập sang hệ thống khác hoặc ảnh hưởng đến các tiến trình không thuộc worker.

Khai thác thành công có thể cho phép attacker thực thi mã với quyền của web worker, từ đó có khả năng đọc dữ liệu mà worker được phép truy cập, thay đổi nội dung hoặc cấu hình của ứng dụng, và làm gián đoạn dịch vụ.

• Với mod_php, đường khai thác đã được xác nhận xảy ra trước khi mã ứng dụng chạy, nên việc kiểm tra riêng từng endpoint ứng dụng không loại bỏ được rủi ro.
• Các request gây OOM cũng có thể làm tăng lỗi xử lý request, làm mất worker hoặc gây suy giảm tính sẵn sàng, tùy SAPI và cách triển khai.
• Phạm vi quyền sau khai thác là quyền của web worker. Dữ liệu hiện có không chứng minh việc tự động nâng quyền lên quyền quản trị hệ điều hành hoặc lan sang hệ thống khác.

1. Nâng cấp từng nhánh PHP bị ảnh hưởng lên release đã sửa tương ứng: 8.2.35, 8.3.36, 8.4.27 hoặc 8.5.12. Với runtime do bản phân phối, appliance, container image hoặc sản phẩm khác đóng gói, cài package đã được vendor backport thay vì chỉ cập nhật PHP trên host.
2. Khởi động lại toàn bộ PHP worker sau khi cập nhật và xác minh không có pool, directory hoặc thiết lập ứng dụng nào ghi đè trở lại cấu hình cũ.
3. Nếu chưa thể cập nhật ngay, PHP khuyến nghị đặt và thực thi memory_limit=-1 ở cấp quản trị để loại bỏ per-request limit có thể tạo ra OOM dễ kiểm soát. Đây chỉ là giảm thiểu tạm thời, không phải bản sửa hoàn chỉnh, và có thể làm một request sử dụng toàn bộ bộ nhớ khả dụng.
4. Giữ post_max_size ở mức thận trọng, áp dụng giới hạn độc lập cho kích thước body đã giải mã tại frontend, giảm max_input_nesting_level, giới hạn số input variable, multipart part, header trong mỗi part và upload. Nếu ứng dụng không dùng multipart form data, chặn loại request này trước khi chuyển đến PHP.
5. Không dùng RLIMIT_AS hoặc RLIMIT_DATA như biện pháp thay thế, vì allocation thất bại qua mmap() có thể kích hoạt chính đường longjmp() dễ bị lỗi. Giới hạn container hoặc cgroup như memory.max có thể hữu ích trong một số triển khai nhưng không phải biện pháp hoàn chỉnh.

1. Lập inventory tất cả runtime PHP phục vụ request, bao gồm PHP chạy qua Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LSAPI và các runtime được đóng gói trong appliance, container hoặc image.
2. Kiểm tra version thực tế của binary, package và image, sau đó đối chiếu với từng nhánh đã được xác định là affected hoặc fixed. Không suy luận rằng một nhánh không xuất hiện trong inventory là an toàn.
3. Kiểm tra cấu hình hiệu lực liên quan đến đường OOM và multipart, gồm memory_limit, post_max_size, max_input_vars, max_input_nesting_level, giới hạn upload, số part và giới hạn header do frontend áp dụng.
4. Rà soát log của web server, PHP và process supervisor để tìm các request lỗi OOM, lỗi request startup, worker thoát hoặc worker được tạo lại. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được PHP xác nhận.
5. Xác minh package source hoặc vendor advisory của từng sản phẩm nhúng PHP để bảo đảm bản sửa đã được backport. Việc không thấy lỗi trong log không chứng minh hệ thống không bị ảnh hưởng.