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.
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 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.
I tend to agree and I often strongly recommend to my clients to choose battle tested off-the-shelf solutions for these problems rather than roll their own, but...
Sometimes it makes sense to roll your own and the cost of a dependency isn't worth it. This can be especially true when you need to accommodate many bespoke environments and you end up needing to make little accomodations here and there. Can create a very unpleasant situation when you don't own the code.
I'm not a cryptographer but I've spent a significant portion of my career focusing on the security-side of things and I've rolled my own auth quite a few times on very public projects you can access today and I've never had any significant findings through repeated pentests.
But that's just the thing: I did it the right way, and there is a right way to roll your own stuff, to forge it in a way it comes out suitable. Is it bug free? Probably not, but I feel significantly better about it having thoroughly tested it by myself, my colleagues and paid professional penetration testers.
I couldn't easily find an answer but I'd like to know if this implementation has been validated by a professional or not.
Well, I tend to fall on your side of this, but doing this probably means you’re equally or more insecure and just won’t know it until you’re hacked. That said, I have written my own auth and session layers numerous times. My needs are generally simple, so getting it correct isn’t too hard.
When you pull in a generic auth or session library, you pull in a “can do everything” module rather than a “can do this one specific thing” module. So, your attack surface grows as do your odds of misconfiguration.
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.
Thinking of use cases where services I build have reasonably low internal userbase. Maybe rolling out own is not worst choice always. After all it leads to manual or at least targeted work by attackers. Instead of very common spraying stuff randomly. So risks might in the end be lower.
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.
90% of those sites don't have anything resembling a sysadmin. If they've not already been hijacked by one of the Wordpress vulns or hijacked plugins years ago, they will be now. And absolutely nobody will spend any effort to fix them, so they will just end up chugging along until safebrowsing flags them and basically removes them from the internet.
Static sites are just superior and i feel like we are going to see a huge shift to SSGs once the average editors realize how much easier it is to have LLMs enter markdown maybe with a bit of html to create their blog posts/articles than to bother with a CMS.
FWIW, a sharp and immediate uptick in support tickets from self-identified WHM resellers and admins who need backups from their rsync.net accounts right now.
I would think that for everyone that needs some help, there must be 10 who self served…
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.
> 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.
You should read the other thread regarding copy fail and the gentoo maintainer. I haven't seen so many unhinged and outright rude comments on a security topic since the good old days of slashdot and x vs. y controversy of the day.
I wonder what the reason behind so much hostility is. Is it gentoo or the kernel folks or the fact that the company that found it used "AI"? No idea, but it was a weird read.
Especially weird when from their description they actually had an idea. ".splice()" and then just searched possibilities of that and then identified place and only then used AI to build something. Which they likely could have done manually too...
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.
definitely don't expose any management interfaces to the open internet.
personally, i manage my homelab through ssh via the commandline, and key-based ssh auth is secure enough for my threat model (i am considering switching the entrypoint machine to a BSD though, to avoid the kind of bugs distros sometimes introduce).
but a webserver and a few containerized services seem pretty low risk to me, so i do have a few of them exposed via reverse proxy. The more sensitive one behind Authelia via the forward-auth pattern, which i feel like is a really good fit for homelabs.
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.
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
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.
Yeah. There are a lot of people saying, “This is why you don’t roll your own…” but if I’d rolled my own, there wouldn’t have been reversible encryption involved, and there certainly wouldn’t have been plain text.
I really feel I have to shill for Fastpanel (www.fastpanel.direct) when it comes to graphical web server UIs.
A couple of years ago I got really sick and tired of cPanel, and started trying all these alternatives. I'm not an Arch Linux SSH freak, I need a GUI. And none of the panels had old school functions like setting up FTP and such.
So good luck to the Estonian (I think?) developers of Fastpanel and good riddance to that bloated slug cPanel.
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?
at the same time, I've never had any faith in that software.
maybe because of it's association with really cheap, buggy hosts i explored in my teenage years. maybe because of their largely unnecessary complications (except enterprise maybe). maybe because of the tendency of large bloated depressing organizations to use these even in places they shouldn't.
not that many software have faith in are faring any better in this cve-storm.
I think you misunderstood. My comment was meant to imply that people would be extra careful about all new software for a while. I know cpanel isn't unproven. It's been around forever.
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)
Yeah, I hate all those terrible regulations that keep people from burning alive in their homes too. Godddamn goverment saving lives, it's so slightly annoying.
Wait. Wasn't there a whole group of people who thought this way recently? Wasn't it called the Department of Government Efficiency? Wasn't it led by a rich tech bro who wants to live on Mars? Didn't they get disbanded because it was a bunch of armchair experts who knew nothing about government and couldn't make anything efficient?
Maybe you want to apply to whatever they're working on next?
What regulations would you suggest would be the software equivalent of a fire code?
What kind of penalties would apply for not meeting these regulations?
Who would be responsible for enforcement? Do you propose this should apply internationally? Or just to software written in a specific region? Or is the location of where software is hosted (or the headquarters of the company operating the hardware) a better target for legislation?
You don't want to see how the sausage is made for medical software. The average quality I would put at below your median SaaS webapp. Security especially is not something you should expect.
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.
“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.
30 years isn't really a good thing, here.
I've been coding for more than 40 years, and I probably only took security seriously, in the last 25 or so.
In fact, in Ye Days of Yore, we often deliberately coded in unsecured stuff, for convenience.
Look at some of the old Apple Systems (pre-OS X), to see some stuff that would make secops people defecate masonry.
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.
I tend to agree and I often strongly recommend to my clients to choose battle tested off-the-shelf solutions for these problems rather than roll their own, but...
Sometimes it makes sense to roll your own and the cost of a dependency isn't worth it. This can be especially true when you need to accommodate many bespoke environments and you end up needing to make little accomodations here and there. Can create a very unpleasant situation when you don't own the code.
I'm not a cryptographer but I've spent a significant portion of my career focusing on the security-side of things and I've rolled my own auth quite a few times on very public projects you can access today and I've never had any significant findings through repeated pentests.
But that's just the thing: I did it the right way, and there is a right way to roll your own stuff, to forge it in a way it comes out suitable. Is it bug free? Probably not, but I feel significantly better about it having thoroughly tested it by myself, my colleagues and paid professional penetration testers.
I couldn't easily find an answer but I'd like to know if this implementation has been validated by a professional or not.
But it's not the same thing every time, for example if you had written 'your own' http request you wouldn't habe been hit by the axios vuln.
If you rolled your own crypto and didn't install AF_ALG, you would have avoided copy fail.
Even in this case if you had implemented your own control panel, you wouldn't be hit.
Actually roll your own, don't add dependencies
Well, I tend to fall on your side of this, but doing this probably means you’re equally or more insecure and just won’t know it until you’re hacked. That said, I have written my own auth and session layers numerous times. My needs are generally simple, so getting it correct isn’t too hard.
When you pull in a generic auth or session library, you pull in a “can do everything” module rather than a “can do this one specific thing” module. So, your attack surface grows as do your odds of misconfiguration.
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.
Thinking of use cases where services I build have reasonably low internal userbase. Maybe rolling out own is not worst choice always. After all it leads to manual or at least targeted work by attackers. Instead of very common spraying stuff randomly. So risks might in the end be lower.
There are well over a million cPanel/WHM installations in the world.
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.
90% of those sites don't have anything resembling a sysadmin. If they've not already been hijacked by one of the Wordpress vulns or hijacked plugins years ago, they will be now. And absolutely nobody will spend any effort to fix them, so they will just end up chugging along until safebrowsing flags them and basically removes them from the internet.
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.
Static sites are just superior and i feel like we are going to see a huge shift to SSGs once the average editors realize how much easier it is to have LLMs enter markdown maybe with a bit of html to create their blog posts/articles than to bother with a CMS.
> 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...
FWIW, a sharp and immediate uptick in support tickets from self-identified WHM resellers and admins who need backups from their rsync.net accounts right now.
I would think that for everyone that needs some help, there must be 10 who self served…
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.
> 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.
You should read the other thread regarding copy fail and the gentoo maintainer. I haven't seen so many unhinged and outright rude comments on a security topic since the good old days of slashdot and x vs. y controversy of the day.
I wonder what the reason behind so much hostility is. Is it gentoo or the kernel folks or the fact that the company that found it used "AI"? No idea, but it was a weird read.
Especially weird when from their description they actually had an idea. ".splice()" and then just searched possibilities of that and then identified place and only then used AI to build something. Which they likely could have done manually too...
> You should read the other thread regarding copy fail and the gentoo maintainer Do you have a link?
It's this one: https://news.ycombinator.com/item?id=47965108
You don’t need CopyFail on these systems if you have this one. This gives you root access to the system through the web interface.
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.
definitely don't expose any management interfaces to the open internet.
personally, i manage my homelab through ssh via the commandline, and key-based ssh auth is secure enough for my threat model (i am considering switching the entrypoint machine to a BSD though, to avoid the kind of bugs distros sometimes introduce).
but a webserver and a few containerized services seem pretty low risk to me, so i do have a few of them exposed via reverse proxy. The more sensitive one behind Authelia via the forward-auth pattern, which i feel like is a really good fit for homelabs.
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.
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
If you want to talk monoculture… cPanel and Plesk are both owned by WebPros the past several years. There’s your #1 and #2 in the space.
Earlier: https://news.ycombinator.com/item?id=47967974
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.
Yeah. There are a lot of people saying, “This is why you don’t roll your own…” but if I’d rolled my own, there wouldn’t have been reversible encryption involved, and there certainly wouldn’t have been plain text.
Anyone who has ever seen cPanel's software engineering abilities (ie any of the source) should not be surprised by this
They should have switched to a web framework long ago
Yeesh, first kernel root exploit, now this...
Low key wonder if people using LLMs to scan these old code bases for corner case issues and fining treasure troves of exploits.
I really feel I have to shill for Fastpanel (www.fastpanel.direct) when it comes to graphical web server UIs.
A couple of years ago I got really sick and tired of cPanel, and started trying all these alternatives. I'm not an Arch Linux SSH freak, I need a GUI. And none of the panels had old school functions like setting up FTP and such.
So good luck to the Estonian (I think?) developers of Fastpanel and good riddance to that bloated slug cPanel.
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?
cPanel is just about as far away from “unproven” as possible.
at the same time, I've never had any faith in that software.
maybe because of it's association with really cheap, buggy hosts i explored in my teenage years. maybe because of their largely unnecessary complications (except enterprise maybe). maybe because of the tendency of large bloated depressing organizations to use these even in places they shouldn't.
not that many software have faith in are faring any better in this cve-storm.
I think you misunderstood. My comment was meant to imply that people would be extra careful about all new software for a while. I know cpanel isn't unproven. It's been around forever.
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.
You’re running cPanel/WHM in a container?
Oh dear.
[dead]
[dead]
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.
Yeah, I hate all those terrible regulations that keep people from burning alive in their homes too. Godddamn goverment saving lives, it's so slightly annoying.
Wait. Wasn't there a whole group of people who thought this way recently? Wasn't it called the Department of Government Efficiency? Wasn't it led by a rich tech bro who wants to live on Mars? Didn't they get disbanded because it was a bunch of armchair experts who knew nothing about government and couldn't make anything efficient?
Maybe you want to apply to whatever they're working on next?
What regulations would you suggest would be the software equivalent of a fire code?
What kind of penalties would apply for not meeting these regulations?
Who would be responsible for enforcement? Do you propose this should apply internationally? Or just to software written in a specific region? Or is the location of where software is hosted (or the headquarters of the company operating the hardware) a better target for legislation?
You're right, there's absolutely no balance you could strike!
Hmm, I wonder how the FDA approves software in a medical devices context. Or if the EU AI act is in any way a precedent.
Oh well, we'll never know.
You don't want to see how the sausage is made for medical software. The average quality I would put at below your median SaaS webapp. Security especially is not something you should expect.
Governments have killed 10-100 times more people than they have protected with regulations.
Not even natural disasters or disease can compete with governments when it comes to mass killings at enormous scales and boundless cruelty.
No.