Everytime I read one of these it always boils down to the same thing..Don't solve solved problems. And the best code in this case is code you didn't write as PHP's session handler is battle-tested but every line you write to roll your own is a line you have to secure, maintain, and eventually patch at 2am when someone finds the bug.
Session handling, auth, crypto, password hashing etc - all these are the exact areas where you should be the most allergic to rolling your own. Not because you're not smart enough, but because a simple bug like sanitizing in the wrong place and the failure is catastrophic like in this instance.
Use boring, proven, widely-audited solutions. Save your creativity for the actual problem you're solving.
I don't even know why you'd want to re-implement this stuff, too. It's not exciting or sexy work. It's like time parsing, time zone handling, leap years... Why would you want to inflict that on yourself? You will 100% not handle every edge case, and you will 100% get time and time zone handling bugs.
Oh you're right to push back. I just love saying this nowadays :P Anyway, I haven't used these languages in a long time but the code looked like php to me, though I did notice the .pm file extension and wondered where I've seen it before.
PHP has built in session handling and the ability to store them to local, in memory, RDBMS database, or you can implement SessionHandlerInterface, SessionIdInterface with your own custom class.
It's probably the most battle hardened session system ever.
I doubt the mantra of "don't roll your own Auth/crypto" - especially if it lives on a server where the code can't be inspected.
Sure, there will be more bugs in my code, but the attackers will be putting far more scrutiny into a widely used library.
Some deliberately hilariously weak auth I built decades ago is only just now starting to get broken into by AI bots, whereas any vulnerable wordpress was broken into within days.
Oooooh that's really bad. Wordpress on Cpanel sites is like the Dark Matter of the internet, it's everywhere and you don't see it until something bad happens. Libations for the sysadmins patching & cleaning up this mess.
What a shame that I no longer have access to my teenage-level conscience, I am sallivating at the idea of going wild with this and the Copy Fail cve.
The potential here to do all kinds of manipulation for search engines / AI tools is enormous. Perhaps the more scary thought is that someone could easily make an agent that would exploit both bugs to wipe out servers.
Good on these companies to publish their findings straight away as I'd imagine that both bugs would have fetched quite a lot on the black market.
I used to help nonprofits and small businesses build websites. Process always went like 1. buy domain, 2. buy a shared hosting provider that one-click-installs Wordpress, 3. use a theme to begin editing the website. Often, I would also use the email included with that hosting provider for the firm.
ALL of that goes through cpanel, for every shared hosting provider I can ever remember using. Even if the stuff happening on those servers didn't use perl, cpanel itself -- the admin of everything provided for that domain by the hosting provider -- it's a huge surface area.
I still deploy a bunch of simple sites, built around the CGI::Application framework.
I understand how they work, I'm familiar with HTML::Template, and related modules, so I can hack up a quick interactive/dynamic site in a couple of hours.
They're no longer things I'd run on the public internet, but for quick internal things it's very easy to deploy a container with a perl backend.
This flurry of activity is certainly going to have people be more apprehensive about unproven software that may be of dubious prominence. My question amid all of this is who else knew about these long-standing vulnerabilities?
I like how the vulnerability is in the path that (a) attempts to write the password in reversibly encrypted form to disk [0] and (b) has a weird fallback path that writes it in clear text. Sigh.
[0] cPabel seems to be from 1996. We’ve known this is a mistake since before 1996.
cPanel being the backbone of the internet's cheap hosting layer was already a monoculture risk waiting to bite us - turns out we didn't have to wait long
Something that is starting to concern me with the flood of cyber chaos in the past couple of months is my homelab. Currently I do not have it set up to be accessible outside the local network and then add it and all my other devices to my tailnet to facilitate remote access (via an exit node on my local network). On top of that TrueNAS doesn't seem to have the best update cadence so I'm worried about having a system with known vulnerabilities only protected by not being accessible remotely in theory.
Really not looking forward to a regulated software industry. It will cause a lot of gatekeeping and bureaucracy. It's one of those things that may seem good, but in practice, it's pure waste in every way imaginable. Will just lead to exclusivity, gatekeeping and artificial friction. This is a hill I'm willing to die on. Those making software have plenty of incentives to make it good, and bad software is punished already to the fullest extend (because it's not fun to get compromised or your reputation ruined; this is a natural incentive)
Everytime I read one of these it always boils down to the same thing..Don't solve solved problems. And the best code in this case is code you didn't write as PHP's session handler is battle-tested but every line you write to roll your own is a line you have to secure, maintain, and eventually patch at 2am when someone finds the bug.
Session handling, auth, crypto, password hashing etc - all these are the exact areas where you should be the most allergic to rolling your own. Not because you're not smart enough, but because a simple bug like sanitizing in the wrong place and the failure is catastrophic like in this instance.
Use boring, proven, widely-audited solutions. Save your creativity for the actual problem you're solving.
I don't even know why you'd want to re-implement this stuff, too. It's not exciting or sexy work. It's like time parsing, time zone handling, leap years... Why would you want to inflict that on yourself? You will 100% not handle every edge case, and you will 100% get time and time zone handling bugs.
“And the best code in this case is code you didn't write as PHP's session handler is battle-tested”
cPanel is written in perl.
Oh you're right to push back. I just love saying this nowadays :P Anyway, I haven't used these languages in a long time but the code looked like php to me, though I did notice the .pm file extension and wondered where I've seen it before.
PHP has built in session handling and the ability to store them to local, in memory, RDBMS database, or you can implement SessionHandlerInterface, SessionIdInterface with your own custom class.
It's probably the most battle hardened session system ever.
cPanel is 30 years old, are you saying it's not battle tested, boring, proven, and widely audited?
In fact PHP is only a few months older than it.
I doubt the mantra of "don't roll your own Auth/crypto" - especially if it lives on a server where the code can't be inspected.
Sure, there will be more bugs in my code, but the attackers will be putting far more scrutiny into a widely used library.
Some deliberately hilariously weak auth I built decades ago is only just now starting to get broken into by AI bots, whereas any vulnerable wordpress was broken into within days.
Oooooh that's really bad. Wordpress on Cpanel sites is like the Dark Matter of the internet, it's everywhere and you don't see it until something bad happens. Libations for the sysadmins patching & cleaning up this mess.
At the rate we are going, we will all go back to publish HTML website like in Geocities times.
Conceptually, static sites are probably not too far off this.
What a shame that I no longer have access to my teenage-level conscience, I am sallivating at the idea of going wild with this and the Copy Fail cve.
The potential here to do all kinds of manipulation for search engines / AI tools is enormous. Perhaps the more scary thought is that someone could easily make an agent that would exploit both bugs to wipe out servers.
Good on these companies to publish their findings straight away as I'd imagine that both bugs would have fetched quite a lot on the black market.
I wonder how much of the web still runs on perl. I miss it sometimes.
I used to help nonprofits and small businesses build websites. Process always went like 1. buy domain, 2. buy a shared hosting provider that one-click-installs Wordpress, 3. use a theme to begin editing the website. Often, I would also use the email included with that hosting provider for the firm.
ALL of that goes through cpanel, for every shared hosting provider I can ever remember using. Even if the stuff happening on those servers didn't use perl, cpanel itself -- the admin of everything provided for that domain by the hosting provider -- it's a huge surface area.
Yeah cpanel navigation is still wired into my brain stem as well.
I still deploy a bunch of simple sites, built around the CGI::Application framework.
I understand how they work, I'm familiar with HTML::Template, and related modules, so I can hack up a quick interactive/dynamic site in a couple of hours.
They're no longer things I'd run on the public internet, but for quick internal things it's very easy to deploy a container with a perl backend.
This flurry of activity is certainly going to have people be more apprehensive about unproven software that may be of dubious prominence. My question amid all of this is who else knew about these long-standing vulnerabilities?
> this vulnerability affects - and we cannot stress this enough - all currently supported versions of cPanel & WHM
yikes. https://www.shodan.io/search?query=basic+realm%3D%22cPanel%2...
I like how the vulnerability is in the path that (a) attempts to write the password in reversibly encrypted form to disk [0] and (b) has a weird fallback path that writes it in clear text. Sigh.
[0] cPabel seems to be from 1996. We’ve known this is a mistake since before 1996.
That's gonna pair really well with this.
https://copy.fail
Why? This one gives you a root shell directly, no need for an LPE.
Container escape.
cPanel being the backbone of the internet's cheap hosting layer was already a monoculture risk waiting to bite us - turns out we didn't have to wait long
Something that is starting to concern me with the flood of cyber chaos in the past couple of months is my homelab. Currently I do not have it set up to be accessible outside the local network and then add it and all my other devices to my tailnet to facilitate remote access (via an exit node on my local network). On top of that TrueNAS doesn't seem to have the best update cadence so I'm worried about having a system with known vulnerabilities only protected by not being accessible remotely in theory.
Earlier: https://news.ycombinator.com/item?id=47967974
Oh dear.
Y'know what would help protect those internet buildings from falling on people? A software building code
Really not looking forward to a regulated software industry. It will cause a lot of gatekeeping and bureaucracy. It's one of those things that may seem good, but in practice, it's pure waste in every way imaginable. Will just lead to exclusivity, gatekeeping and artificial friction. This is a hill I'm willing to die on. Those making software have plenty of incentives to make it good, and bad software is punished already to the fullest extend (because it's not fun to get compromised or your reputation ruined; this is a natural incentive)
Not a very good one given the frequent data leaks from large companies. May not be fun but the bottom line continues along unabated.