New printers can be okay. I don’t know of any specific problems with new printers except those ones with the ink subscription services. I’m saying my printer is old because it’s from another time. The only reason you’d isolate your networked printer in 2005 would be if you didn’t want other people to access your printer. Devices in your home automatically, deliberately making themselves worse on command from a cloud service was not a thing. The biggest danger with devices this old is that they probably have unpatched security vulnerabilities exploitable by anything else that gets on your network.

I have a VR headset from Facebook that is on its own VLAN because it defaults to randomizing its MAC address by default and this allowed it to bypass the firewall, phone home, and nonconsensually install new anti-features after being blocked because the setting got reset back to random when changing something. Recent LG TVs and other devices with worse preinstalled malware have been known to make requests to other devices on your network, but I’ve never heard of them using those other devices to get around network restrictions, at least not directly.

1 is enough if the hardware manufacturer is currently trustworthy at the time you put the firewall rules in place. Brother is AFAIK trustworthy. I have a Brother printer which is on my main network with no special firewall rules, but my printer is old enough to drink. It never connected to any cloud services and could never update itself to introduce new anti-features.

For both 2 and 3 you probably want a Raspberry Pi or other server to make the printer accessible to devices on your main network. Unless it’s a Facebook or Amazon or LG printer or something you should be fine with just 1.

They’re not the same. https://www.youtube.com/watch?v=3FICjyf-e8k

I’ve heard it has to be specifically an Apple ARM CPU if you’re doing this for energy efficiency. Maybe things have improved, but probably not because all the resources go to LLMs.

The container thing is extremely unlikely. However, having worked with developers before, I know there are people who are running those AWS and Azure images with internet-facing SSH password authentication. If they hadn’t already been hacked, they’ve all been hacked now. Somebody just had to check Shodan for hosts in those IP ranges running OpenSSH and try a few usernames.

And there’s an account in the container that has a password set. That’s already a security problem on its own.

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 https://www.youtube.com/watch?v=7CiZmq2llDg&t=629s they first find the vulnerability but their AI cheated to make it exploitable and then somebody else gives them a way to leak memory to figure out where things are in memory. 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.

https://github.com/TecharoHQ/anubis/blob/main/docs/docs/admin/botstopper.mdx

You need a new name. Plume already exists.