Results 26 to 35 of 35
Thread: SymLink Vulnerability cPanel
-
01-31-2013, 01:07 PM #26Junior Guru
- Join Date
- Jul 2011
- Location
- Sittingbourne, Kent, UK
- Posts
- 197
RackSRV Communications Limited
UK specialists in Dedicated Servers & Server Colocation
Company: 06856870 VAT: GB 934 7073 15 Tel: 0330 111 4444
-
01-31-2013, 06:23 PM #27WHT Addict
- Join Date
- Jul 2010
- Posts
- 123
As I said previously, if you only apply the Apache patches attack vectors still exist. Not only that, but I know for a fact script kiddie distributed tools exist to take advantage of those vectors and the script kiddies specifically target shared cPanel hosting providers with said tools.
Kernel level patching is needed. I believe Igor at Cloudlinux and Spengler over at GRSec have already implemented similar kernel work to what we run on our shared kernel to patch these vulnerabilities. If you want to be truly secure and free of these types of hacks you need to employ one of their methods or develop something similar.
-
01-31-2013, 10:34 PM #28Web Hosting Master
- Join Date
- Jun 2001
- Location
- Princeton
- Posts
- 1,029
For anyone who things that preventing some functions at PHP level will work:
You can always use PHP script to create/modify .htaccess file and add a CGI handler (even if you have CGI disabled at cPanel level).
After that create & execute perl script as CGI -- creating all the links you want, and bypassing any PHP related restrictions.Igor Seletskiy
CEO @ Cloud Linux Inc
http://www.cloudlinux.com
CloudLinux -- The OS that can make your Shared Hosting stable
-
02-01-2013, 04:08 AM #29Web Hosting Master
- Join Date
- Nov 2004
- Location
- Australia
- Posts
- 1,737
While this is a common feeling, it's not actually true that kernel level patching is required to fix this, nor is it actually a kernel bug per se. The unix kernel is doing what it's always done; what introduces the security hole is partly the way Apache interprets symlinks in a multi-user environment running suphp, and partly the lack of protection in file modes (ie usually 644 instead of 600).
The problem here is that Apache can be asked to read a file that is not normally accessible if a symlink is created. There is a setting in Apache called SymLinksIfOwnerMatch that mostly fixes this, but it may be possible for a user to override it and we've seen hackers do just that. The thing that makes this work is that it allows a hacker or skript kiddie to escalate a hack to cover the entire server. There are now several patches that help fix this - the StevenC/Rack911 one forces SymLinkIfOwnerMatches to always be on, and the bluehost patch fixes the race condition in checking the symlink ownership.
A simple and very solid fix is to ensure the mode of PHP files on your system is 600 - that way the symlink doesn't have permission to read the files and the exploits don't work.
I have some cron scripts that do this primitively but effectively at www.whmscripts.com and also there's a collation of some useful links and other patches there.
Please note - I'm not knocking the obvious usefulness of patches created by Igor in CloudLinux, just wanting to introduce a little more clarity to the discussion. Apologies in advance if I'm wrong on some point.
Unless I'm missing something, this isn't Unix permissions at all - the problem is that a process with group read permission to the folder is allowing access from another account. That doesn't hold true for other non-privileged processes - either running as PHP or CGI on the server (it does if you allow CGI to run as the generic apache user, but then you have very serious problems anyway as that's an issue in itself).
ps: totally, utterly, agree with Igor that disabling PHP functions is a complete waste of time. There are 100 other ways of making symlinks ...
-
02-01-2013, 07:39 AM #30Web Hosting Master
- Join Date
- Jun 2001
- Location
- Princeton
- Posts
- 1,029
brianoz, you are correct -- kernel patch is not needed if you can make sure files are 600 or even 640 (and owned by user:user group).
It doesn't prevent explaratory symlinks (like ln -s / 1.txt) that lets user browse the system, but it prevents user from reading php files.
There is also a way (with a patch) to piggy back on SuexecUserGroup tag for virtualhost, and prevent symlinks attacks on php files -- even when they have other+read bit set -- which is quite secure (unlike SymLinkIfOwnerMatches).
So, kernel solution by far is not the only solution.
Yet, I see two problems with cronjobs:
1. Scanning all users files on regular intervals to see if they have proper permissions is undue stress on IO
2. You are still leaving time between scans for hacker to exploit.
I know some hosting companies are using AV scanners that hook into FTP/sftp and check all uploaded files. Similar hooks can be used to 'fix' permissions.
Also, some tools just use INOTIFY to monitor all filesystem changes in /home directory. This can also be used (but costly on start up) to fix permissions.Igor Seletskiy
CEO @ Cloud Linux Inc
http://www.cloudlinux.com
CloudLinux -- The OS that can make your Shared Hosting stable
-
02-01-2013, 11:01 AM #31WHT Addict
- Join Date
- Jul 2010
- Posts
- 123
I still have to disagree. I've seen a 0 day PoC that leverages race conditions to exploit the behavior previously mentioned -- Igor I believe Dave may have mentioned or shown you as well. Plus even if that were not the case not using a kernel level solution at minimum causes dirty intensive workaround and leaves you open for information disclosure attacks.
-
02-01-2013, 02:57 PM #32Web Hosting Master
- Join Date
- Jun 2001
- Location
- Princeton
- Posts
- 1,029
Patrick, there are many things at once:
1. SymLinkIfOwnerMatch does have race condition/easily exploited
2. in my last discussion with Dave -- we concluded that Apache approach (which piggy backs on SuexecUserGroup) that we have & kernel approach are not exploitable via race condition
3. Information disclosure is still there -- no matter what you do. Kernel or not. We closed it down using CageFS - either way, symlinks is not the best way (though often used) to gain list of users or domains from the server.Igor Seletskiy
CEO @ Cloud Linux Inc
http://www.cloudlinux.com
CloudLinux -- The OS that can make your Shared Hosting stable
-
02-01-2013, 10:34 PM #33Problem Solver
- Join Date
- Mar 2003
- Location
- California USA
- Posts
- 13,681
One thing that people need to remember is, once you are compromised via this attack vector.. it doesn't matter how you patch it someone, has your customer scripts database details server wide.
A pretty rigorous cleaning needs to be done, and you need to advise all customers to change their database passwords.
Otherwise.. after you patch you will repeatedly be hacked.. despite being patched.Last edited by Steven; 02-01-2013 at 10:41 PM.
Steven Ciaburri | Industry's Best Server Management - Rack911.com
Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance
-
02-02-2013, 02:13 AM #34WHT Addict
- Join Date
- Jul 2010
- Posts
- 123
-
02-02-2013, 06:44 PM #35Web Hosting Master
- Join Date
- Nov 2004
- Location
- Australia
- Posts
- 1,737
Permission on root filesystems (/home, etc) should prevent most exploration.
Ah - brilliant - thanks for sharing this.
True, there is time after a file is uploaded, however an hourly cron chmod job on the obvious public_html/*config* mostly closes this, and you'd have to be really unlucky for a hacker to guess.
I know some hosting companies are using AV scanners that hook into FTP/sftp and check all uploaded files. Similar hooks can be used to 'fix' permissions.
Also, some tools just use INOTIFY to monitor all filesystem changes in /home directory. This can also be used (but costly on start up) to fix permissions.
I get your points about the window and the exploration though on another level - the kernel fix does close those nicely and it's awesome that you/CloudLinux have put such careful work and thought into producing a solid fix.
Perhaps I'm paranoid but I see a place for solutions at a variety of levels as so often a fix at just one point is too easily bypassed by a future variation to the technique. eg the race condition workaround for the first stab at the SymLinkIfOwnerMatch patch. It's a little like the "switch to suphp and everything's secure" mentality.
Steven - exactly, once bitten there's a hell of a lot of cleanup work. Now we need someone to help cleanups by writing a tool to go through and change all database passwords in both files and in the database!Last edited by brianoz; 02-02-2013 at 06:47 PM.
Similar Threads
-
cPanel Vulnerability?
By joecooper in forum Web HostingReplies: 6Last Post: 02-22-2012, 06:07 PM -
Password Protect Symlink in cPanel
By w00ts!te in forum Hosting Software and Control PanelsReplies: 0Last Post: 07-23-2009, 02:17 PM -
cPanel Horde Vulnerability Found - Please update your cPanel ASAP
By Virtuoso Host in forum Hosting Security and TechnologyReplies: 14Last Post: 03-09-2008, 02:35 PM -
SIM installer symlink attack + race condition local root vulnerability
By jpetersen in forum Hosting Security and TechnologyReplies: 0Last Post: 04-29-2007, 01:54 PM -
CPanel vulnerability
By aah-jim in forum Hosting Software and Control PanelsReplies: 1Last Post: 02-19-2003, 09:27 AM