SANS finds published php2shell exploits unreliable outside lab setups
Original title: (Reliable)? php2shell exploitability, (Fri, Oct 23rd)
Working demos need an 8 MB memory limit, one prefork worker and on-box library offsets, and commands are capped at 14 bytes.
Bojan Zdrnja at the SANS Internet Storm Center reviewed published php2shell proofs of concept and concluded a universal one-click exploit is difficult. Demos that work first force allocator failure under an 8 MB memory_limit on a single prefork worker, then leak heap and libphp.so addresses using offsets read from the target binary. He recommends setting session.upload_progress.enabled to 0 until the next update, saying a bypass of the current fix apparently exists.
Unconfirmed: The author says he did not thoroughly check phase 3 and that the original researchers may know more.
- One PoC posts 1001 fields of 3000 bytes, then a 12 MB field.
- Typical memory_limit values are about 128 MB, and real servers use multiple workers.
- Phase 2 leaks zval_ptr_dtor; its offset depends on PHP build, version and distro.
- Phase 3 redirects pDestructor to zif_system, with commands limited to 14 bytes.
Impact: Remote code execution limited to a 14-byte command
| Product | Affected |
|---|---|
| PHP | — |
- 1.Set session.upload_progress.enabled to 0 until the next PHP update.
- Products
- PHP
- Organizations
- SANS Internet Storm Center
From the original article
2 min read at isc.sans.eduYesterday everyone was running around like crazy (me included :) because of the php2shell vulnerability.
isc.sans.edu
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.