We are already using CageFS and yes this can help you to overcome on this issue.
- Status
Being a New Admin to WHM, I am Shocked that cPanel has not found a Solution for this or at least provided a Guide on how to prevent Symbolic Link Hacking in a Shared Hosting environment.
This is the eleventh page with no Actual Definitive Information on how to Stop the Hacking.
Yet the Thread on this Hack has been around for a Year.
Has anyone actually Solved this?
This is the eleventh page with no Actual Definitive Information on how to Stop the Hacking.
Yet the Thread on this Hack has been around for a Year.
Has anyone actually Solved this?
CloudLinux has: SecureLinks
and there are some 3rd party patches provided in this thread that you may be interested in as well.
SecureLinks is something that we need to pay for. We pay already for cPanel, quite high price (almost $30 a month for 1 server), so I think we can expect implementing some patches into Easyapache. Not every WHM / cPanel admin is familar with this thread, so cPanel should be a step before all of us, and provide such extra help as module in Easyapache.
Jeff,
I'm afraid I agree in that my feeling is that cPanel is letting down the community by not providing a fix. At the very least, the fact that this major security hole has been left unpatched by cPanel could result in perpetuating the myth that cPanel is insecure.
Make no mistake - this is a hole that allows nearly every site on a server to be hacked through database connections; it really couldn't be any more serious. Additionally, this has been around for long enough unpatched that it will be getting into the kits that script kiddies run. This will only cause more and more pain for all, including cPanel support, if left unpatched.
To top this off, there's been recent news that there's a race condition allowing exploit of this vulnerability despite applying Steven's patch. We really, really need a patch that checks ownership of the opened file via fstat(2) before providing the contents of the file; we need it now; and we need it included in cPanel by default. Nobody has developed a patch like this yet, but it's the correct solution.
Pointing to CloudLinux or other 3rd party fixes, IMO, just isn't good enough - this is a serious gaping hole in core software provided by cPanel, and this is an opportunity for cPanel to step up pace to demonstrate it's willing to take it's mantle of market leadership seriously when called on.
Sorry to be so blunt (it's beer o'clock here in Australia); obviously I'm a big fan of cPanel but this hole really makes me nervous.
Thanks for the forthcoming response!
I'm afraid I agree in that my feeling is that cPanel is letting down the community by not providing a fix. At the very least, the fact that this major security hole has been left unpatched by cPanel could result in perpetuating the myth that cPanel is insecure.
Make no mistake - this is a hole that allows nearly every site on a server to be hacked through database connections; it really couldn't be any more serious. Additionally, this has been around for long enough unpatched that it will be getting into the kits that script kiddies run. This will only cause more and more pain for all, including cPanel support, if left unpatched.
To top this off, there's been recent news that there's a race condition allowing exploit of this vulnerability despite applying Steven's patch. We really, really need a patch that checks ownership of the opened file via fstat(2) before providing the contents of the file; we need it now; and we need it included in cPanel by default. Nobody has developed a patch like this yet, but it's the correct solution.
Pointing to CloudLinux or other 3rd party fixes, IMO, just isn't good enough - this is a serious gaping hole in core software provided by cPanel, and this is an opportunity for cPanel to step up pace to demonstrate it's willing to take it's mantle of market leadership seriously when called on.
Sorry to be so blunt (it's beer o'clock here in Australia); obviously I'm a big fan of cPanel but this hole really makes me nervous.
Thanks for the forthcoming response!
Last edited:
I don't disagree. If there were a 12 page thread in the Feature Requests for cPanel & WHM for this, then there may be a better chance of seeing a patch implemented from cPanel. I urge one of you to create a thread there, and email/tweet/facebook/text/whatever the link to everyone you know, asking them to reply to it with their support.
You guys should also be voicing your opinion toward those responsible for this issue, which is the Apache group. The fact that they create an unsafe feature while providing another feature as a workaround which their own documentation says isn't even effective is puzzling. If everyone in the hosting industry who is concerned about this issue demanded from Apache that they address this problem, this thread may not have ever been necessary.
Keep the updates coming. I stand with you guys and will voice my support as well. This shouldn't have ever been an issue, and absolutely shouldn't still be an issue.
You guys should also be voicing your opinion toward those responsible for this issue, which is the Apache group. The fact that they create an unsafe feature while providing another feature as a workaround which their own documentation says isn't even effective is puzzling. If everyone in the hosting industry who is concerned about this issue demanded from Apache that they address this problem, this thread may not have ever been necessary.
Keep the updates coming. I stand with you guys and will voice my support as well. This shouldn't have ever been an issue, and absolutely shouldn't still be an issue.
Last edited by a moderator:
I can disable madspot shell from symlink to any user in my server. Just prevent php.ini overwritten/uploaded by user and don't allow .htaccess FollowSymlink BUT all my client has an error.. Fuhh there are too many support ticket that we are facing now.
I can't use CloudLinux since I'm on OpenVZ..
I can't use CloudLinux since I'm on OpenVZ..
Why don't you just move this thread to feature requests....
Cpanel seem to use the excuse that users didn't jump through hoops 1-20 and that's why nothing is being done. Sorry doesn't make sense - if you value your software surely a cpanel staff member would bring issues to the attention of cpanel devs....?
Infopro
Well-Known Member
Hi Michael, I've asked the cPanel Product Manager @cPanelKenneth about this. His comments mirror cPanelJeff's, above. "This is an Operating System vendor issue. Patching Apache is only a partial solution and the patches available are still subject to race conditions. cPanel is not an Operating System vendor, does not touch the kernel, nor most tools on the system. Taking this to the Vendor is the way to go and/or using something like GRSecurity to solve the problem."
That reads to me like this is out of cPanel's hands, not an excuse full of hoops to jump thru.
I hope that post makes sense to you.
Stevens patch + good disable_functions in php.ini + disable cgi server wide + disable zip unpacking by users + permanent cron control = 99% safety....
I don't follow the 99% safety. 99% safety is not safety if the hackers are aware to exploit the 1% unsafe scenarios, right? Then again, I suppose there really is no such thing as 100% safety
You need to disable "ExecCGI" and "Options All" in .htaccess files for Apache configuration. You can do this by disallowing Opions override in httpd.conf , and disabling ExecCGI prior to this.
You can disable zip unpacking (or any archive unpacking) by editing cPanel file manager options and also by removing ZIP from php.
- - - Updated - - -
You can disable zip unpacking (or any archive unpacking) by editing cPanel file manager options and also by removing ZIP from php.
- - - Updated - - -
That is why I post: 99% not 100.... there is no 100% security.Then again, I suppose there really is no such thing as 100% safety
Shocked that an advisory e-mail hasn't been sent out to cPanel users with discussion of this issue and potential solutions.
In my case, I implemented this change:
to my /usr/local/apache/conf/includes/pre_virtualhost_global.conf
and then did this to find all the .htaccess files on my server that contain +FollowSymLinks:
and systematically went through all of them and changed +FollowSymLinks to +SymLinksIfOwnerMatch.
All in all about 5 minutes work.
In my case, I implemented this change:
Code:
<Directory "/home">
Options +All -ExecCGI -FollowSymLinks +Includes +IncludesNOEXEC -Indexes -MultiViews +SymLinksIfOwnerMatch
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>and then did this to find all the .htaccess files on my server that contain +FollowSymLinks:
Code:
find /home -iname ".htaccess" -exec grep -l "FollowSymLinks" {} \;All in all about 5 minutes work.
Last edited:
Glad to hear that the solution I provided was useful to you.
This change really does work well and isn't tough to implement at all, it just requires a bit of support going forward to keep your users informed of what they need to change in their .htaccess files if they try to use +FollowSymLinks (such as some common scripts like Joomla provide by default).
what about to follow the steps given below. will these steps help in anyway ?
+Steven patch
+Restrict safe_mode globally with the help of suphp .
+Disable dangerous php functions through php.ini .
+Disable options ExecCGI +FollowSymLinks+Includes+Indexes under Main >> Service Configuration >> Apache Configuration >> Global Configuration
+Disable the option Automatically create a cgi-bin script alias under Main >> Server Configuration >> Basic cPanel & WHM Setup
+Steven patch
+Restrict safe_mode globally with the help of suphp .
+Disable dangerous php functions through php.ini .
+Disable options ExecCGI +FollowSymLinks+Includes+Indexes under Main >> Service Configuration >> Apache Configuration >> Global Configuration
+Disable the option Automatically create a cgi-bin script alias under Main >> Server Configuration >> Basic cPanel & WHM Setup
- Status
