Hacker News Reader

Comment by tptacek | Hacker News Reader

What does "non trivial to exploit from just public requests" mean? It's known to be exploitable on more than one stock PHP application. This really is a 5-alarm fire.

View on HN

I think people are just latching onto the post that hit the front page earlier today about it being non-trivial to exploit, combined with the fact that there seem to be about a billion PoC out there, most of which don't work.

The most direct exploit requires a compromised supply chain which ranks it about as dangerous as your usual dependency exploits.

I think this is just false? Are we playing some kind of weird game of telephone? Is the term "direct exploit" doing way more work in that sentence than you mean it to?

The alternative route through the web forms requires the absence of ASLR. So you need to spam the endpoint, like a lot. You can probably mitigate at the edge (CDNs) or perhaps at the reverse proxy level (NGINX) through e.g. rate limiting. More of a web version of row hammer then some sort of trivial SQL injection attack that works consistently.

Maybe a LAMP stack on an extremely ancient version of Linux is vulnerable out of the box. Quit the fear mongering please, you do the security community no favors.

Say what you will about OpenAI, Wiz etc but if OpenAI, Wiz, Cloudflare, the PHP Foundation and pretty much every CERT out there together recommend to take down PHP apps and patch immediately then I'm very much inclined to follow that advice.

Due to the insane media coverage there'll of course be a deluge of PoCs, most of which won't work. But constantly refreshing Twitter to see whether there's a working PoC is not a good use of time nor a great security strategy.

Right, that's what's worrying me. It is not interesting that the most widely circulated public POC/demos don't work. All you should care about is the (currently) non-public POCs that do work, of which there are apparently several.

My PoC (generated) was able to exploit an index.php with a simple echo.

The only thing you have to know in advance is the relative memory offset distances, and that's it. Memory feng shui was the longest part of the implementation.

[1] https://github.com/cookiengineer/actual-php2shell

Try finding a modern Linux distro without ASLR enabled defaults.

> ASLR

Read the heap feng shui doc, and headline 4 in the README.

The involved heap feng shui is independent of ASLR.

... and maybe read up on what ASLR actually does and how memory arenas work before trying to be smart?

Did you even read the diff, it synthesized intentionally vulnerable code which trivializes the exploitability

I would assume he didn’t read anything in the repo. It also requires disabling ASLR.

Eh, no?

It is split up into two branches and demos, see the heap feng shui document?

ASLR enabled requires a way to create more data, which I intentionally did not create in the index.php because other folks claimed that is "cheating". That was the demo that wiz created.

Maybe you should read the repo next time? It is literally headline 4.

The whole point of this demo is that the assumed to be hard part (mem feng shui) is what LLMs are actually good at.

why read the diff? my AI agent reads the diff and ignores stuff it knows I don' want to hear.

Reply on news.ycombinator.com