EGreg

But wont be supplied. Get used to disappointment :)

Remember folks, while you wait for your patches, you might want to install a proxy to prevent these things from happening:

https://news.ycombinator.com/item?id=50330367

Wait, but what if you worked hard for 10 months iterating with a chatbot, which used an LLM to write the code behind the scenes?

You didn't write the actual code by hand, but you did iterate a lot and fix a lot of bugs, etc.

Where are the bugs in Uniswap? Aave marketplace?

I miss the old days of decentralized networks, and smart contracts that were audited. Forget the shitcoin memecoins and zero sum games mania, the NFTs and the prediction markets. There is so much positive sum that can be done:

https://intercoin.org/applications

https://community.intercoin.app/t/fund-for-refugees/2688

Indeed, very shortly since digital computers were invented, there was corruption. For years, until the voltage could be controlled better and until IEEE standardized things.

Indeed, very shortly since modems were invented, there was need for error correction. They were slow and clunky. The only reasonable conclusion is that the Internet is a fad and not worth discussing. Same as this newfangled decentralized cryptography stuff.

Indeed, very shortly after the Web came out, regular script kiddies could write php websites with blink tags. Credit card numbers were sent in the clear with http. This “e-commerce” thing was a dangerous joke, only idiots would send their credit cards over the Internet. It would never catch on!

You misunderstand. The very reason that this Binance hack is a huge issue is that $5B was concentrated in specific wallets under specific keys.

A decentralized network of wallets and balances doesn’t present an attractive target for hackers specifically because the payoff per wallet is so small!

It is exactly the centralization you are defending, which is at the root of the problem. In the decentralized case, no one has to determine who is a student or a teacher. If a teacher needs to pass KYC with a marketplace, they do it once, and from then on can permissionlessly receive their small payouts.

I know what’s going to happen. I will explain what crypto is for and then it will get downvoted just because it says anything positive about crypto.

The point is to NOT have a single place with access to all the money, votes, etc. Every participant should be acting as themselves, and there should be no way to do things on behalf of others without their consent.

The point of smart contracts is to have code you can actually trust. Your bank or openAI can change their website, APIs and even their models tomorrow. That’s not great for trust. Trust is what enables things to scale.

The same way you trust other internet protocols to just “route around problems” and not have one single point of failure, that is the substrate for Web3.

Imagine a Web2 website such as a student-teacher marketplace NOT handling millions of dollars, accepting money from students and paying them out to teachers. Imagine it being simply an interface while the actual transactions are approved by the students themselves, and instead of the central site signing payouts with some keys, the teachers get paid through smart contracts and code on the blockchain. The site can still take 10% commission from everything, it would be above board, and it can never change it without the consent of the people. The business logic is in the smart contract.

(Since this comment has the keywords “crypto” and “web3”, I know what will happen in advance already.)

Notice that the hacking is mostly happening with centralized venues. And that is to say nothing of FTX, Celsius etc.

The original promise of crypto and blockchain was to cut out the middleman and NOT concentrate a lot of money under a few custodial keys.

If you took your crypto off exchanges when not in use, you’d be fine. Not your keys, not your crypto.

how do we know? it could be nonsense...

I’ll be straight with you… I think it’s the RLHF. That is the most load-bearing aspect

Instead of what patch? I just said this is for those who have NO PATCH AVAILABLE. I guess you need the strawman to make a valid point, though…

A lot of PHP environments were set up years ago, and run versions below PHP 8.1. If they don’t do something, eventually, they might be exploited, and turned into botnets or worse. A lot of the old PHP forums and other websites might get back door doors and impersonate people, etc.

I developed a proxy that sanitizes input before it reaches PHP. I had to put it together quickly, but since then, I’ve made it a lot more user-friendly, including PHP installation scripts that automatically scan your Web server configuration, and suggest exactly how to install the proxy. The proxy itself is written in C, and I recommend running it under a Linux user that has absolutely no file permissions. All it’s supposed to do is transform input into safe output. I would argue that this proxy might even be safer than the patch, because it might prevent other vulnerabilities that researchers haven’t found yet.

It’s just a generally good idea to sanitize input before it reaches your app servers anyway. But if you are running and older PHP environment, I don’t think there are any other good options than this…

https://github.com/Qbix/proxy

The mindset that every hacker and tinkerer has. Trying to take the system apart and decouple it.

Meanwhile most people just do the traditional thing

What if you ask your AI to make it for you based on the site?

Also, the Web is already open source

Because when you are trying to put out a fire, the fact that the fire extinguisher can fall over a year from now it’s not a irrelevant reason not to put out the fire.

Right. But it can’t, for several reasons: 1) The proxy is open source and much simpler than PHP runtime or a web application. Its code only takes input and generates output. It is basically a pipe. It has no other capabilities to exploit. 2) The operating system, such as BSD or Linux, supports running processes under a user and enforces limits on that user. So you just jail this proxy — since it has one purpose. Unlike your application, which may do many things and you can’t restrict it, it may become a confused deputy

Me too. You should be.

It’s very simple to check it though. And to sandbox it to have zero read and write permissions to any files. About all it can do in a malicious direction is drop requests or deliver malformed requests, and it is straightforward to see there is no way the code will allow that.

I wonder how much of their output is simple raw “superpositions” and how much is from far more generalized emergent structures as it is trained and has to learn latent representations.

Only the first layer is a “mashup” of the raw data, other layers start to recognize patterns across the data!

Right. But it can’t, for several reasons:

1) The proxy is open source and much simpler than PHP runtime or a web application. Its code only takes input and generates output. It is basically a pipe. It has no other capabilities to exploit.

2) The operating system, such as BSD or Linux, supports running processes under a user and enforces limits on that user. So you just jail this proxy — since it has one purpose. Unlike your application, which may do many things and you can’t restrict it, it may become a confused deputy

What this has taught me is that we should decouple as much as possible into microservices, so that we can properly sandbox each service, and that way we have chokepoints.

Well, PHP is in C, and I know C much better — but certainly this proxy is so simple, an LLM or even a mechanical program could transpile it to Rust or Go.

Either way, memory leaks here aren’t too relevant.

I just posted about it here a half hour ago: https://news.ycombinator.com/item?id=50197861

Well yes, but we have to think logically.

Relying on this patch, you're only protected against these specific CVes, but in general a proxy can protect you from more. It's strictly additive security, right?

And if you can't or won't patch your PHP, this is strictly better than getting pwned and having your PHP-FPM execute arbitrary commands. That's as bad as it gets, and you better hope that Linux user permissions can constrain it, but your apps are basically gone. PHP-FPM even allows PHP to overwrite .php files, meaning next time they are hit, it's completely arbitrary code that persists.

As a side note: https://qbixserver.com is a project I started several months ago, that is a pure PHP server without needing nginx, and it forks after loading your classes, instead of preforking like php-fpm. It's not vulnerable to php2shell, and it is able to rewrite php code on the fly when it loads it, to make it more safe. It does things like disallowing your php scripts to write to .php files, and it makes require($filename) check that $filename actually ends in .php ... a lot of stuff like that.

The security added by this proxy is strictly additive, it can't make things worse. This proxy can be run by a Linux user with no permissions at all, so it just transforms input. Can it have a sleeper code that transforms input in a way that causes your PHP to do something even worse? Well, this is why you should point Claude at the repo and ask it if it has any backdoors. It's completely open source and GitHub actions has been used to build the binary. So I guess if you don't trust GitHub, you can also compile it yourself, but then you're trusting GCC. (Ken Thompson has an interesting talk on Trusting Trust of compilers, from 30 years ago.) But at this point we're way past what people usually are concerned about.

I don’t know why everyone is so hung up on this patch being the only way to fix the situation. The way that Internet services are attacked is by crafting malicious payloads. Having a proxy in front of your application server is a very smart idea, especially if it can do one job: decode input, and re-encode it in a safe way. In a couple hours, I put together a proxy using Claude, which completely eliminates this php2shell attack and many other others, that might possibly be discovered in the near future. Among other things it just decodes and re-encodes multipart-form-data payloads with its own random sane delimiters rather than attacker-chosen ones.

We use it ourselves in our deployments, and yesterday I released it free under MIT license, for anyone who is unwilling or unable to patch their PHP (which is probably millions of servers right now):

https://github.com/Qbix/proxy

Love it! Finally somebody gets it.

I got downvoted heavily by other HNers for merely offering a solution to protect people’s legacy PHP servers. They said it should be deleted and “not worth working on”. The solution was free and open source but these downvoters commented as if it was worse than having your server PWNED. I still don’t understand why.

For those who can’t patch their PHP for a variety of reasons right now, here is a proxy I developed that can sit between nginx or apache and your PHP-FPM, to sanitize inputs and prevent this (and other) attacks:

https://github.com/Qbix/proxy

Not to be harsh, but what you said is completely irresponsible and harmful.

Leaving people completely unprotected to the entire Internet when their servers are now vulnerable to arbitrary, remote, command execution, is about as bad as it gets.

People can have their large language model review the code in about 15 seconds. It’s quite minimal. They can also simply run the proxy as a Linux user that has zero permissions for most things like writing files. This is literally just a proxy that sanitizes input.

I could understand if you actually at least clicked and looked at the repository, and read what it’s about. But you chose to simply write generic text without looking at anything. You want to discourage people from protecting their servers, in order to feel good about yourself. What amount of effort have you put into understanding what you’re even talking about?

If your AI found a possibility of a memory leak, please actually point to the source code, or better yet submit a request. And a possible gradual memory leak, as a reason to not do this, really? None of this is as bad as NOT protecting your server.

Verify it

GitHub actions builds from source

Yes, PHP maintainers have released a patch for the latest versions of PHP.

If you're running earlier versions, or you're on a host that maintains PHP for you, you're unprotected... for a long time.

This is a proxy I have quickly put together, to use on our own legacy environments. It's free and open source (MIT license).

Recommendations:

1. Run it under a Linux user with no permissions to access any files. It's just a pure proxy -- transforming input into output on a network port.

2. Modify your server files (nginx, apache, etc.) to use the proxy in proxy_pass etc. before it hits your PHP. Boom, your apps should be protected.

3. As with any git repo, run it through an LLM. Do not take my word for anything... if you find any bugs, please submit a pull request.

Hope this helps the community that hosts websites with PHP! (aka 80% of the web)

Out of memory?