Security - cPanel zero day

And they are already heavily abused, there is a scan script and update solution for this part.
I don't know if that also covers the copy_fail issue on CP.
 
Hopefully we won’t see a similar 0-day on the DirectAdmin side. The cPanel issue looks quite serious and seems to be getting exploited quickly. Regardless of the control panel, the underlying infrastructure (especially the Linux kernel and related services) is always a risk point. Keeping everything up to date and applying additional security measures seems essential.
 
Hopefully we won’t see a similar 0-day on the DirectAdmin side. The cPanel issue looks quite serious and seems to be getting exploited quickly. Regardless of the control panel, the underlying infrastructure (especially the Linux kernel and related services) is always a risk point. Keeping everything up to date and applying additional security measures seems essential.
Indeed, this is why you almost always follow the principle of "keep everything up to date." Doesn't mean you won't be affected by 0-day exploits, but you've done the best you can to guard against an exploit that may or may not have been disclosed.

A new kernel comes out? Update and reboot. That's the best philosophy. And before someone says Kernelcare, I'm not sure that I fully trust Kernelcare to patch everything. Some things in the kernel just have to be patched up with a new kernel. And with SSD/NVMe drives and kexec these days, a reboot costs you 30 seconds.
 
Indeed, this is why you almost always follow the principle of "keep everything up to date." Doesn't mean you won't be affected by 0-day exploits, but you've done the best you can to guard against an exploit that may or may not have been disclosed.

A new kernel comes out? Update and reboot. That's the best philosophy. And before someone says Kernelcare, I'm not sure that I fully trust Kernelcare to patch everything. Some things in the kernel just have to be patched up with a new kernel. And with SSD/NVMe drives and kexec these days, a reboot costs you 30 seconds.

The "problem" with this specific CVE wasn't the update ...speed from customers/admins but cpanel's ignorance.
cPanel was notified ~64 days before the patch about this from the researcher and the answer he got was "not to worry about it's nothing".
So an almost ~2 months attack surface for root - that even bypasses 2FA was caused by cpanel's ignorance.

Just like kernelcare, they couldn't patch in time the copy-fail, their own recommendation was to block the module and reboot. Took them ~2 and a half days to patch this (today 1st of May)
 
scary. I was very very nervous as I do have a few servers on cpanel. Only 1 VPS customer was affected and he lost everything but luckily we found tar.gz backups on the server which seemed to not be encoded and could easily restore those.
 
Kernelcare is only patching the running kernel in memory, so if you want to have a new patched kernel, yes, you still need to reboot.

I have also seen some servers taking around 10 minutes for running fsck when they were rebooted after a few years running. Some other database servers take a few minutes for rebooting when having large cache. In any case, if you want to reboot, you should schedule downtime with your customers, just in case...
 
Mine are 45 seconds before the logo even shows up. And the a couple of minutes before 100 VMs begin to be started. I usually expect 5 minutes before everything is running again. If you are simply running a VM then yes 30 seconds.
 
Back
Top