Security - Recommended update to httpd.conf files via custombuild

Hi John, please check if StevenC patch can be used instead, so that we don't have to deal with clients complaining about the .htaccess restriction: http://forums.cpanel.net/f185/how-p...inks-non-root-users-202242-p4.html#post996441 Here is copy of StevenC post:

I hate cpanels stance on this so we have created a patch and have been using for some time. It turns FollowSymLinks into SymLinksIfOwnerMatch at the apache source code level.

We currently are working on rewriting the patch, and part of apache to take care of some possible race conditions. But given the rare race condition possibility, this is by far a better option than causing everyone to have to reconfigure their .htaccess files or allowing your server to be wide open to attack.

How to install our patch (apache 2.2 only):

Code: 
wget http://layer1.rack911.com/before_apache_make -O /scripts/before_apache_make 
chmod 700 /scripts/before_apache_make
#Rebuild apache after. 
/scripts/easyapache

If you have any issues, let us know, we would be interested in hearing it.
If you want to thank us, your free to do that aswell.

When trying to access a file located in another account via a symlink, you will see this in the error log:

Code: 
[Sun Nov 06 05:06:23 2011] [error] [client xxxxxx] Symbolic link not allowed or link target not accessible: /home/xxxxx/public_html/1/confirm.txt

Also, find out if your already a victim:

Code: 
find /home*/*/public_html -type l
Click to expand...
 
Last edited:
Hello,

Done.

If you wish to use the StevenC/Rack911 patch, it's now in custombuild. It's off by default.
Right now, it's just in files1, so please allow 24 hours if you're using a files mirror for rsync propogation.

To use it:
Code: 
cd /usr/local/directadmin/custombuild
./build update
./build set harden-symlinks-patch yes
./build set secure_htaccess no
./build apache
./build rewrite_confs
Some cases, ./build apache will delete modules from /usr/lib/apache... so if that happens, you'll also need to do
Code: 
./build php n
and for any other missing modules.

What this patch does, is allows Users to use everything as it was before, including the FollowSymLinks option.
However, the functionality of FollowSymLinks is no longer the insecure type as it was before.
The new functionality of FollowSymLinks with this patch will simply duplicate the functionality of the more secure SymLinksIfOwnerMatch.
This will allow the secure_htaccess option to be set to "no" (old httpd config setup), but still solve the linking issue with regards to security.

Once testing is under the belt for this patch, we'll set secure_htaccess=no as the default, and harden-symlinks-patch=yes as the default.

John
 
Hi, John. Thank you very much! Great! I will implement the patch tonight. :)
 
DirectAdmin Support said:
Hello,

Done.

If you wish to use the StevenC/Rack911 patch, it's now in custombuild. It's off by default.
Right now, it's just in files1, so please allow 24 hours if you're using a files mirror for rsync propogation.

To use it:
Code: 
cd /usr/local/directadmin/custombuild
./build update
./build set harden-symlinks-patch yes
./build set secure_htaccess no
./build apache
./build rewrite_confs
Some cases, ./build apache will delete modules from /usr/lib/apache... so if that happens, you'll also need to do
Code: 
./build php n
and for any other missing modules.

What this patch does, is allows Users to use everything as it was before, including the FollowSymLinks option.
However, the functionality of FollowSymLinks is no longer the insecure type as it was before.
The new functionality of FollowSymLinks with this patch will simply duplicate the functionality of the more secure SymLinksIfOwnerMatch.
This will allow the secure_htaccess option to be set to "no" (old httpd config setup), but still solve the linking issue with regards to security.

Once testing is under the belt for this patch, we'll set secure_htaccess=no as the default, and harden-symlinks-patch=yes as the default.

John
Click to expand...


Thats Awesome!
 
I get this problem and httpd is down:

[root@*** custombuild]# ./build rewrite_confs
Using ***.***.*** for your server IP
Writing data to /etc/httpd/conf/extra/httpd-suphp.conf
Done.
Restarting apache.
Stopping httpd: [ OK ]
Starting httpd: Syntax error on line 26 of /usr/local/directadmin/data/users/adv
Unknown DAV provider: svn

[root@server custombuild]#
 
My entire /etc/httpd/conf/httpd.conf seems to have been overwritten! And lost a lot of settings there. :(
 
Why he would? Because it's stated you should do that in post #23 from DA support.

This is an option I found in Zencart:
## the following line is needed to allow Download-By-Redirect to work
Options +FollowSymLinks
Click to expand...

Will this keep on working in good order after doing the patch?
 
Last edited:
DirectAdmin Support said:
Hello,

Done.

If you wish to use the StevenC/Rack911 patch, it's now in custombuild. It's off by default.
Right now, it's just in files1, so please allow 24 hours if you're using a files mirror for rsync propogation.

To use it:
Code: 
cd /usr/local/directadmin/custombuild
./build update
./build set harden-symlinks-patch yes
./build set secure_htaccess no
./build apache
./build rewrite_confs
Some cases, ./build apache will delete modules from /usr/lib/apache... so if that happens, you'll also need to do
Code: 
./build php n
and for any other missing modules.

What this patch does, is allows Users to use everything as it was before, including the FollowSymLinks option.
However, the functionality of FollowSymLinks is no longer the insecure type as it was before.
The new functionality of FollowSymLinks with this patch will simply duplicate the functionality of the more secure SymLinksIfOwnerMatch.
This will allow the secure_htaccess option to be set to "no" (old httpd config setup), but still solve the linking issue with regards to security.

Once testing is under the belt for this patch, we'll set secure_htaccess=no as the default, and harden-symlinks-patch=yes as the default.

John
Click to expand...

Why don't you turn on harden-symlinks-patch as default?
 
Hello,

For anyone who is using the patch, are there any noticeable issues? The patch should be the default, as it makes life much easier.
If all is well (let me know), then I'll make it the default for new installs. Will need several confirmed reports that it's working before we change it (we're using it on a test box, and it's fine as far as we can tell)

John
 
Hi, I have been running with the patch for about a week now. Everything looks okay, but I am getting some Segmentation Faults in Apache:

Code: 
[Tue Jan 10 09:34:39 2012] [notice] child pid 77443 exit signal Segmentation fault (11)
[Tue Jan 10 09:34:39 2012] [notice] child pid 77364 exit signal Segmentation fault (11)
[Tue Jan 10 09:34:39 2012] [notice] child pid 77352 exit signal Segmentation fault (11)

I don't know if this is related to the patch or not, as it could be just APC acting up (or something else that I have played with). I haven't looked into it that much.

FreeBSD 7.4 x64, Apache 2.2, PHP 5.2.17 CLI

Now that I think about it, I didn't rebuild PHP after applying the patch. I'll be doing so tonight once I upgrade to PHP-CGI. I'll follow-up once I go through.
 
I've got it running on Centos 5.5 with mod_ruid2 for about three or 4 days and have the same problem you have and I did rebuild php after applying the patch:
[Tue Jan 10 00:39:13 2012] [notice] mod_ruid2/0.9.4 enabled
[Tue Jan 10 00:39:13 2012] [notice] Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 DAV/2 PHP/5.2.17 configured -- re$
[Tue Jan 10 00:40:36 2012] [notice] child pid 11019 exit signal Bus error (7)
[Tue Jan 10 00:40:41 2012] [notice] child pid 11021 exit signal Segmentation fault (11)
[Tue Jan 10 00:40:44 2012] [notice] child pid 11017 exit signal Segmentation fault (11)
[Tue Jan 10 00:40:45 2012] [notice] child pid 11018 exit signal Segmentation fault (11)
[Tue Jan 10 00:40:45 2012] [notice] child pid 11020 exit signal Segmentation fault (11)
[Tue Jan 10 00:40:45 2012] [notice] child pid 11031 exit signal Segmentation fault (11)
[Tue Jan 10 00:40:45 2012] [notice] child pid 11034 exit signal Segmentation fault (11)
[Tue Jan 10 00:40:46 2012] [notice] child pid 15859 exit signal Illegal instruction (4)
[Tue Jan 10 00:40:46 2012] [notice] child pid 17250 exit signal Illegal instruction (4)
[Tue Jan 10 00:40:46 2012] [notice] caught SIGTERM, shutting down
[Tue Jan 10 00:40:46 2012] [notice] seg fault or similar nasty error detected in the parent process
Click to expand...
So I think it's not your APC but indeed the patch which is causing this. However, I only had this once until now.

Centos 5.5, PHP 5.2.17 (cli) (built: Jan 10 2012 00:40:19)
Server version: Apache/2.2.21 (Unix)
Server built: Jan 10 2012 00:36:43
 
Hi John. Is there any way I can apply the patch without running ./build rewrite_confs , like adding the needed code in confs files manually? I am getting errors when running ./build rewrite_confs because I have two files in custom folder, virtual_host2.conf and virtual_host2_secure.conf and running a customized DA SVN plugin like this: http://www.directadmin.com/forum/showthread.php?t=38010&p=191619#post191619 - I get errors after running ./build rewrite_confs like this:

Code: 
Starting httpd: Syntax error on line 26 of
/usr/local/directadmin/data/users/...

I have attached the content of my virtual_host2.conf and virtual_host2_secure.conf files as attachments, they are needed in order for domain creating of IDN domains to work without errors when using the SVN plugin.
 

Attachments

... but what is the error? If some of the main httpd.conf files are missing the svn bits (eg: LoadModule), then it would be easier to lock them down, so that everything can still be re-written, but for any main conf file, it will be locked and won't be able to be modified.
http://help.directadmin.com/item.php?id=351

John
 
Hi, sorry for the incomplete error message, here all of it is:

Code: 
[root@server custombuild]# ./build rewrite_confs
Using 12.12.12.12 for your server IP
Writing data to /etc/httpd/conf/extra/httpd-suphp.conf
Done.
Restarting apache.
Stopping httpd:                                            [  OK  ]
Starting httpd: Syntax error on line 26 of 
/usr/local/directadmin/data/users/adv
Unknown DAV provider: svn

[root@server custombuild]#

Also I have previous been talking to you on email, but I have not any solution yet. Please see the email with subject "httpd down after rewrite_confs" where I have provided all information that I have. The emails is from december 22 and 23. You have replied to them.
 
Basically, after the rewrite, what do you do to fix it? Do the user httpd.conf files get manually changed? Or is something re-installed to re-add code to the main conf files in /etc/httpd/conf/* ?
One way to find out is to make a backup of the user httpd.conf file when it's working, issue the rewrite, then see if it's changed at all. If it has, then something is editing the user httpd.conf behind DA's back, which wouldn't be recommended.
If the user httpd.conf file is the same, then the change is in the /etc/httpd/conf/* location (somewhere), so you'd just need to lock it, as mentioned in the id=351 guide. (or use the cleaner solution #2 in id=351 to add the custom code confs (under the custombuild dir), so the custom conf is copied upon each re-write)

John
 
You must log in or register to reply here.
Back
Top