i_am_not_a_robot

I don’t know if they can be disabled, but I think the memory limit is actually the problem. One of the vulnerabilities is related to how PHP handles exceeding a memory limit. I don’t know if it’s the same limit you’re thinking of. I have been avoiding PHP for a long time. If it were that simple, I’d have expected the advisories to mention it as a mitigation.

Besides the problem of people being able to do this themselves, there’s the problem of people who develop and sell, or sometimes give away, exploits. The people scrambling to publish POCs without verifying that they’re demonstrating the right vulnerabilities are unintentionally helping out by making it difficult to find how to exploit the real vulnerabilities. Like what are you supposed to search for “php2shell exploit for real not fake?” You almost need an AI agent in a sandbox to download and run all the POCs to weed out the fake ones until one of them becomes well known.

I don’t think any of those walls help except for a WAF that knows what to look for. I don’t know exactly what the real exploits look like but I heard something about constructing multipart form bodies that expand to a surprisingly large amount of PHP memory compared to the size of the request body, and that’s probably something a heuristic on a WAF could detect. I would want to do more research before relying on that.

It’s too soon. Only people who are on top of things would have already noticed, and then even after people notice they’re probably going to want to do investigations and get PR people and lawyers involved before making any public announcement. We’re more likely to hear the consequences from dark web forums first.

Yes, and even for Debian because of ASLR, but these vulnerabilities may allow memory to be leaked and from those memory leaks an attacker can reconstruct the necessary information. That’s obviously not something just anybody could have done, but publicly available AI tools have made this level of attack complexity much more accessible. In www.youtube.com/watch?v=7CiZmq2llDg&t=629s they first find the vulnerability but their AI cheated to make it exploitable. I don’t think having errors enabled is actually necessary for the exploit to work, because if that was the case the PHP security announcement would have said “turn off errors” instead of “turn off your server now.”

Those PoCs are fake. You can exploit a page that just prints “hello.”

This is dangerous misinformation. Both PHP bugs are real and together they are exploitable without the server having some other rare problem.

The vulnerability is in PHP. This FreshRSS release addresses the vulnerability by updating the version of PHP in the container image. If you’re not using the official FreshRSS container image, you just need to update your PHP.

github.com/TecharoHQ/anubis/…/botstopper.mdx

You need a new name. Plume already exists.

This guy has been spamming all over Lemmy.

If you have local SMTP and IMAP you can send mail on your own systems, or if you’re not using containers and you run everything on the same system you may even be able to skip SMTP and just deliver directly. But if you want to receive mail from outside your LAN you’ll need a way to access your IMAP server.

It is kind of a hassle to get all your DNS set up so your mail doesn’t go to spam. If you don’t already know what you’re doing it will probably take over an hour.

I verified my domain with Proton and I can send mails from my domain through their servers and pass all sender verification and reputation tests. This works without needing to control a public IP in a range that is allowed to send mail to the common mail services.

What do you do if somebody adds your IP to the crowdsourced blocklist used by your server?

This kind of thing has been going on since long before “AI.” Expect anything connected to the internet will have failed login requests. That’s why there is a login system.

Can you just connect a regular drive using a USB SATA adapter or something?

KDE Connect can do all three of these.