All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
PHP Extended Support - what exactly is this?
I came across this on the IONOS web site and...wait a sec, do companies really think these hick spokespeople work? I guess they must. Anyway:
"PHP Extended Support
Keep using older PHP versions with PHP Extended Support from IONOS. Versions 4.0, 5.2, 5.4, 5.6, 7, 7.1 and 7.2 are all supported, saving you the hassle of upgrading."
In their help desk article they say "As part of the PHP Extended Support, IONOS security experts ensure that security vulnerabilities affecting older PHP versions continue to be closed. Your PHP projects and scripts will remain protected from attacks until you decide to switch to a current PHP version. Maintaining the old PHP versions means an increased administration effort on our systems. We charge you a monthly fee for this additional service."
I notice Dreamhost offers this too.
On the one hand, these are big companies (e.g., IONOS, according Wikipedia: 2K employees, 8 million customers) and "paying for legacy support" is common. On the other hand, we're talking about a publicly-exposed massive attack surface and the skeptic in me think this is less "we have independently security-audited legacy PHP versions and back-ported fixes" and more "we'll install old crap and charge you extra and if you get hacked, oh well".
Comments
php 4.0, thx
I think its this. https://www.cloudlinux.com/features/#hardened-php
EDIT- I might be wrong though after reading it a little.
I'd say it's CloudLinux, yes.
It's hard to guarantee security when you don't staff Zend's development team on these matters. The likelihood of exploiting something in the VM is far harder to prove than to disprove the attack originated in stagnant code.
These prilimary service operations are managed devops.
Application have to updated and mantained by customers.
There's no way they're patching security holes in PHP 4.0.
They probably use a web application firewall and write rules for exploits that can be detected based on the request headers or body, similar to how Cloudflare didn't used to let you write
cat /etc/passwd
on this forum.Even then, they'd only be doing reactive protection rather than proactive.
Sounds like Cloudlinux to be honest
Were there any serious widespread vulnerabilities intrinsic to PHP itself? I mean, most exploitation can be attributed to crappy configuration or piss-poor app development practices, and that is something you can shoot yourself in the foot with even in the latest version.
The only reason for me paying for Cloudlinux on my main servers.
Don't bother. Always use upstream supported releases - https://www.php.net/supported-versions.php
I have seen open source code where they fix security holes with "fix typo" as commit message. No CVE attached. Developers are lazy. I wonder how Cloud Linux keeps up with the PHP codebase? Do they read each commit? Recently, PHP had a bus factor of probably 2 or 3. nikic (Nikita Popov) who worked for JetBrains and worked on PHP source code resigned and joined the LLVM project. Then Jetbrains panicked and started a PHP foundation - https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/
The JIT engine is maintained by Dmitry Stogov (bus factor 1? not sure) There were some interviews before where some PHP maintainers (sara golemon?) said laughingly - "no one really understands most of Dmitry's code since it is too low level and complex and only he knows what he's doing".
Last year, around March 2021 - PHP official git server (self hosted) was hacked and backdoor was added - https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d#diff-a35f2ee9e1d2d3983a3270ee10ec70bf86349c53febdeabdf104f88cb2167961R370
nikic found this and reverted it https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a?branch=2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a&diff=unified#diff-a35f2ee9e1d2d3983a3270ee10ec70bf86349c53febdeabdf104f88cb2167961R368-R370
The PHP core devs had to check every commit for that timespan lmao and then they moved all the repos from the self hosted git instance to github.com to avoid any future potential shitshow.
Luckily the foundation is healthy? and everything seems to be running fine now - https://opencollective.com/phpfoundation
You still can’t write that*:
In theory, though, you could bypass it by setting a variable:
(or however you choose to hide the string)
Edit: I think it depends whether or not you’ve embedded it into a sentence (not sure)
@raindog308
Oh well, just yet another way to generate profit (or to keep the customers). No way too dirty to make money!
It's like accessing IPMI over old versions, eventually nobody has the IE or java available to even login or hack your shit. Security through obsolescence?
This is why I keep my most private documents on a tape on a Commodore 64.