Nghiên cứu OrcaCyber - PHP2Shell: Cách một yêu cầu thất bại trở thành Thực thi mã từ xa

Bản chứng minh khái niệm trong cuộc điều tra này được tạo ra bằng các mô hình OrcaCyber Zero và OrcaCyber Ultra. Bộ hồ sơ nghiên cứu ghi lại phân tích ở cấp độ mã nguồn, một bản tái hiện có kiểm soát sử dụng bản khai thác công khai đã được điều chỉnh, một hiện vật tiết lộ bộ nhớ, các vụ sập tiến trình và bằng chứng thực thi lệnh. Các tệp được cung cấp không ghi lại một cách độc lập những bước nào đã được từng mô hình thực hiện; việc quy gán mô hình do nhóm nghiên cứu cung cấp.

Tình trạng hết bộ nhớ nghiêm trọng phải chấm dứt một yêu cầu một cách an toàn. Ở đây, nó có thể ngắt PHP khi trạng thái native mới chỉ được khởi tạo một phần, để lại các tham chiếu tồn tại sang yêu cầu tiếp theo. Kết quả là vi phạm vòng đời bộ nhớ xuyên yêu cầu với hậu quả từ tiết lộ thông tin đến thực thi mã từ xa trong môi trường được thử nghiệm.

Bằng chứng chính trong nháy mắt

• Mục tiêu — PHP 8.4.26, Apache/mod_php, một worker duy nhất, phòng thí nghiệm Docker biệt lập.

• Nhật ký sự cố — Một lần thoát worker do SIGABRT và ba lần thoát worker do SIGSEGV trong đoạn trích được cung cấp.

• Phản hồi HTTP — 819.200 byte trong giá trị PHPSESSID đã giải mã URL.

• Bằng chứng thực thi — code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>.

• Hồi quy — Báo cáo mô tả bốn nỗ lực không thành công trên PHP 8.4.27 đã được vá; các lần chạy thô không được đính kèm.

Nguồn: các tệp đã tải lên REPORT.md, crash_evidence.log, leak_attempt.resp và rce_proof_8426.txt. Các vật chứng được mô tả dưới đây tái hiện những tệp đó dưới dạng bảng bằng chứng được sắp chữ; chúng không phải là ảnh chụp hay ảnh chụp màn hình terminal gốc.

1. Lỗ hổng: lỗi sở hữu ranh giới yêu cầu

Hai vấn đề liên quan này xoay quanh việc khởi tạo yêu cầu bị gián đoạn và các con trỏ toàn cục runtime cũ. Trong kiến trúc PHP liên quan, việc xử lý multipart/form-data và các callback tiến độ tải lên của phiên có thể chạy trước mã ứng dụng người dùng thông thường. Một chuyển đổi luồng điều khiển bất thường, bao gồm code>zend_bailout()/code>, có thể bỏ qua việc dọn dẹp dự kiến và để trạng thái trỏ đến bộ nhớ mà sau đó bị giải phóng hoặc tái sử dụng.

Bất biến bảo mật: một tham chiếu toàn cục theo worker được lộ ra cho yêu cầu B tuyệt đối không được tham chiếu đến vùng nhớ mà quyền sở hữu và vòng đời đã kết thúc cùng với yêu cầu A. Lỗi được báo cáo đã vi phạm bất biến đó.

Điểm cuối được minh họa là một trang PHP tối giản chỉ đơn giản trả về OK; kịch bản khai thác không phụ thuộc vào các điểm cuối SQL injection, file inclusion hoặc deserialization ở cấp ứng dụng.

2. Trình tự kỹ thuật

• A1 — gián đoạn. Việc xử lý nhiều phần và tiến độ tải lên gây OOM trong quá trình dọn dẹp, để lại trạng thái phiên cũ.

• B1 — rò rỉ. Một yêu cầu tiếp theo khiến quá trình tuần tự hóa cookie phiên đọc vượt quá một ID phiên hợp lệ.

• Khôi phục địa chỉ. Các giá trị con trỏ bị rò rỉ được sử dụng để suy ra bố cục thư viện và heap liên quan trong bản dựng đó.

• A2/B2 — hỏng dữ liệu. Một chuỗi hai yêu cầu khác định hình và chuyển hướng dữ liệu cũ được dùng khi tắt máy.

• Kết quả. Bản khai thác công khai đã được điều chỉnh báo cáo việc thực thi lệnh dưới danh nghĩa www-data.

Các vật chứng: những gì các tệp được cung cấp thực sự thể hiện

Bằng chứng A — chấm dứt worker từ nhật ký Apache

• code>[core:notice] [pid 1:tid 1] AH00051: child pid 54 exit signal Abort (6), possible coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: tiến trình con pid 55 thoát với tín hiệu Segmentation fault (11), có thể có coredump trong /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: tiến trình con pid 58 thoát với tín hiệu Segmentation fault (11), có thể có coredump trong /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: tiến trình con pid 61 thoát do tín hiệu Segmentation fault (11), có thể có coredump trong /etc/apache2/code>

Trích đoạn được dàn trang từ crash_evidence.log (ngày 23 tháng 10 năm 2026). Nhiều lần worker thoát cho thấy lỗi an toàn bộ nhớ; chỉ riêng các vụ crash không chứng minh được RCE.

Phụ lục B — Phản hồi HTTP có cookie phiên bất thường

• code>HTTP/1.1 200 OK/code>, với dữ liệu nhị phân được lược bỏ.

• code>Server: Apache/2.4.69 (Debian)/code>

• code>X-Powered-By: PHP/8.4.26/code>

• code>Set-Cookie: PHPSESSID=[dữ liệu nhị phân đã lược bỏ]/code>

• Độ dài cookie đã mã hóa: 2.330.754 byte.

• Giá trị sau khi giải mã URL: 819.200 byte.

Số đo được tính trực tiếp từ leak_attempt.resp. Giá trị nhị phân được cố ý bỏ qua để tránh tái tạo bất kỳ nội dung tiến trình bị rò rỉ nào.

Phụ lục C — bằng chứng thực hiện

code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>

Nội dung chính xác của rce_proof_8426.txt, như được cung cấp. Nội dung này củng cố kết quả thực thi đã được báo cáo nhưng không phải là bản ghi đầy đủ của lệnh/phiên.

Phụ lục D — sửa lỗi vòng đời phiên

• code>static inline void php_rinit_session_globals(void)/code>

• code>@@ -121,6 +120,7 @@ static inline void php_rinit_session_globals(void)/code>

• code>* mã hóa lại phiên trong quá trình khởi động yêu cầu, trước RINIT, khi chưa có người dùng/code>

• code>/* Chạy trước RINIT: không được gọi mã người dùng, xem php_session_unserialize_init() *//code>

• code>/* Đoạn này chạy trước RINIT, vì vậy chúng ta cần xóa sớm những thứ này *//code>

• code>php_rinit_session_globals();/code>

Các dòng diff mã nguồn được chọn từ session.c.diff. Thay đổi này đặt lại rõ ràng trạng thái toàn cục của phiên sớm hơn RINIT thông thường.

3. Tại sao bằng chứng lại quan trọng

Việc rò rỉ bộ nhớ tạo cầu nối giữa một sự cố tiến trình và một chuỗi khai thác. Một giá trị session có kích thước bất thường chứa dữ liệu nhị phân nhúng phù hợp với việc runtime diễn giải bộ nhớ không hợp lệ như một chuỗi Zend. Báo cáo nghiên cứu mô tả thêm việc trích xuất địa chỉ code và heap từ cửa sổ bị rò rỉ. Gói bằng chứng chứa phản hồi thô nhưng không có script độc lập chứng minh mọi địa chỉ được khôi phục.

Artifact RCE cho thấy ngữ cảnh bảo mật www-data. Nó không thiết lập quyền truy cập root, không chứng minh việc xâm nhập môi trường production, cũng không chứng minh tính di động hoàn toàn sang các triển khai PHP tùy ý. Cấu hình phòng thí nghiệm một worker là quan trọng vì trình tự yêu cầu và worker affinity ảnh hưởng đến cơ chế.

4. Sửa tận gốc vòng đời nền tảng, không chỉ khắc phục triệu chứng

Bản diff mã nguồn được cung cấp cho commit bản vá PHP 01a40e89fbfc ("Avoid state corruption via bailout") cho thấy việc khởi tạo sớm các biến toàn cục phiên, những thay đổi trong xử lý OOM của bộ cấp phát và logic đặt lại/dọn dẹp mở rộng hơn. Những thay đổi này nhằm ngăn trạng thái native tồn tại qua một yêu cầu bị gián đoạn ở trạng thái không hợp lệ. Chỉ sửa đường dẫn mã hóa cookie sẽ không, tự nó, khôi phục được đảm bảo quyền sở hữu bộ nhớ này.

Báo cáo nghiên cứu nêu rằng các nỗ lực nhắm vào PHP 8.4.27 đã không tạo ra cookie bất thường, sự cố crash hay bằng chứng RCE trong bốn lần thử. Các bản ghi thực tế của phiên bản đã vá không có trong gói này, vì vậy so sánh đó được báo cáo như một quan sát của nhà nghiên cứu chứ không phải một bằng chứng có thể kiểm tra độc lập.

5. Các hành động phòng thủ

• Ngay lập tức. Nâng cấp nhánh PHP được hỗ trợ bị ảnh hưởng lên bản phát hành đã được sửa lỗi bảo mật và sử dụng khuyến cáo của nhà cung cấp để xác nhận tình trạng chính xác của gói.

• Giảm thiểu phơi nhiễm. Cân nhắc hạn chế đầu vào multipart và tắt code>session.upload_progress/code> nếu không dùng; những biện pháp này không thay thế bản vá.

• Phát hiện.Xem xét các sự cố sập trong quá trình khởi tạo yêu cầu, lỗi 500 bất ngờ và kích thước quá lớn của code>Set-Cookie/code> trong tiêu đề phản hồi.

• Đảm bảo. Kiểm thử lại với các nhóm worker đại diện cho môi trường production và xác thực rằng trạng thái phiên cũ không thể tồn tại qua các yêu cầu.

6. Phương pháp nghiên cứu của OrcaCyber

Nhiệm vụ nghiên cứu có giá trị không chỉ là phát hiện các thao tác không an toàn riêng lẻ; mà còn là truy vết toàn bộ một vi phạm bất biến xuyên suốt quá trình phân tích cú pháp yêu cầu, hành vi của bộ cấp phát, các biến toàn cục native thường trú, tuần tự hóa và tắt hệ thống. OrcaCyber Zero và OrcaCyber Ultra đã được sử dụng để tạo PoC trong cuộc điều tra này, theo ghi nhận của nhóm nghiên cứu. Bộ hiện vật công khai hỗ trợ việc tái tạo kỹ thuật, nhưng không cung cấp dấu vết thực thi theo từng mô hình cũng như không chứng minh việc phát hiện lỗ hổng một cách tự động.

Thang bằng chứng: giả thuyết mã nguồn → tác nhân kích hoạt có thể tiếp cận → lỗi khi chạy → rò rỉ thông tin → bằng chứng thực thi → kiểm thử hồi quy trên phiên bản đã sửa. Chuỗi này tạo độ tin cậy mạnh hơn so với một mô tả lỗ hổng hoặc kết quả chỉ có crash. Nó cũng khuyến khích báo cáo rõ ràng về sự không chắc chắn khi không có tệp mã nguồn hoặc nhật ký thực thi thô.

7. Phạm vi và hạn chế

Tài liệu này mô tả một phòng thí nghiệm Docker biệt lập được ủy quyền. Khai thác này dựa trên nghiên cứu PHP2Shell đã được công bố trước đó, với phần điều chỉnh cục bộ được ghi lại trong báo cáo đi kèm. Gói này bao gồm các tập lệnh, diff, byte phản hồi, nhật ký và đầu ra bằng chứng, nhưng bỏ qua bản checkout đầy đủ của mã khai thác thượng nguồn, ảnh chụp màn hình nguyên bản và bản ghi thô đầy đủ của hồi quy bản vá. Không có tuyên bố nào về việc nạn nhân hoặc khách hàng ngoài đời thực bị xâm phạm.

Nguồn và tạo tác

Nguồn chính: tệp php2shell-report-bundle.tar.gz được cung cấp (REPORT.md; report-CVE-2026-109618.md; report-CVE-2026-109619.md; crash_evidence.log; leak_attempt.resp; rce_proof_8426.txt; các bản diff mã nguồn PHP). Bối cảnh công khai: các khuyến cáo bảo mật PHP GHSA-w8hw-w9fx-j79w và GHSA-6wmf-4rv5-p3rp; các thông báo phát hành bản vá bảo mật PHP. Ghi nhận khai thác công khai: 9bie/php2shell-bypass-aslr-exp. Kho nghiên cứu: orcacyber-php2shell-research.

Điểm mấu chốt: một yêu cầu đã thất bại; một con trỏ vẫn tồn tại; yêu cầu tiếp theo đã tin tưởng nó. Phần khó của việc hiểu lỗ hổng này là thiết lập mối liên hệ đó bằng bằng chứng có thể quan sát được.