• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Deny from all does NOT block php- and pl-files

chris-taylor

New Pleskian
The environment:
Ubuntu 8.04 LTS
Plesk 9.5.4
PHP as FCGI
The situation:
Block access for a directory by setting up an .htaccess file with the following content:
deny from all
This implies that all files in the directory are NOT accessible.
BUT php- and pl-files are still accessible!!!
This is an absolutely unexpected behaviour...(Deny means DENY !?)
The Parallels support was not able to fix this problem!!!
(I reported it and they only came along with no-working "solutions"...)
By trial and error I figured out that the problem is caused by the following lines in the domain specific httpd.include file:
<Files ~ (\.php)>
SetHandler fcgid-script
FCGIWrapper /var/www/cgi-bin/cgi_wrapper/cgi_wrapper .php
Options +ExecCGI
allow from all
</Files>

The problem is invoked by the folowing line:
allow from all
Removing this line would be the solution for the problem...
How can I get rid of this line???
I also tried to setup additional lines in vhost.conf like:
<Files ~ (\.php)>
SetHandler fcgid-script
FCGIWrapper /var/www/cgi-bin/cgi_wrapper/cgi_wrapper .php
Options +ExecCGI
</Files>
But this does not override the given line:
allow from all

I urgently need a solution for this sh.t problem!!!
My clients expect that all files in a protected directory are blocked!!!

All help appreciated

Many thanks in advance


Christian
 
What if you add this into your .htaccess file?

<Files ~ (\.(php|pl))>
deny from all
</Files>

deny from all

Does that change anything?
Also, do you get a different behavior if you run php as an apache module or cgi mode instead of FCGI?
 
Hello,

thank you for your response...
You are right, when I place the following lines in the directory's .htaccess file:

<Files ~ (\.(php|pl))>
deny from all
</Files>
deny from all

php and pl files are inaccessible - like all other files in this directory.

Nevertheless this approach is not satisfying.

I'll try to clarify my point of view:
In my opinion DENY means DENY and not some files may be delivered nonetheless...

My Plesk installation here is setup in an university environment
with more than 200 Users who are more or less laymen in web technologies...
These users will expect that a "deny from all" will block the whole directory content.
My former web environment worked like that and also all web environments of comercial providers
I used for my private webspace so far....
Plesk's behaviour in this situation is totally unexpected!!!
Taking into consideration that this is a standard situation
which will occur hundreds of times here, I will have to inform all users
that a "deny from all" in .htaccess is not sufficient
for protecting directory content.

Stupidly the faulty configuration part for php- and pl-files is hardcoded
in the websrvmng binary as I figured out so far.
I tinker with the idea of patching the binary e.g. replacing the first a
of the "allow from all" line in the websrvmng binary with a comment character (#).
Hopefully this disables the faulty line....

Has anybody tried this before?

Another question I've got:
Why hasn't anybody else stumbled across this misbehaviour?
(In my opinion this is a severe security issue...)

Thank you for your comments!!!

Regards


Christian
 
I understand your frustration, but I dont think most people do that task while using fcgi so it may not be all that widespread or known. You can try and put in a ticket with support but in my experience even when it is a bug or their fault it can take years for them to deem it worthy of fixing.

At least at this point you have a work arround - another may be not to use fcgi and to try the apache DSO or cgi version of php instead and see if that changes the behavior.
 
Hello,

Thank you very much for your help!!!

Meanwhile I've solved the issue by using a hex editor... ;-)
The hex editor workaround is doing well...
But I will have to be aware of changes when updating Plesk...

(For me this seems to be the only solution...at the moment)

Thank you again for your help...


Regards

Christian
 
keep in mind that plesk periodically rebuilds the httpd.include from scratch - so if you modify that file you will most likely loose your changes, whether thats today or tomorrow, next week, or a year from now - it will happen.

With that said, you should be safe to make those modifications in the vhost.conf - Plesk shouldnt mess with that. If you are creating one from scratch you should also run this command afterwards

/usr/local/psa/admin/bin/websrvmng -v -u --vhost-name=domain.com
 
I know about the httpd.include file being updated every time the websrvmng-binary is executed
(/usr/local/psa/admin/bin/websrvmng).
So I patched this binary to produce the correct httpd.include entries (without "allow from all"). ;-)

Thank you for your warning.
Because of this patch I will have to be aware of every update Plesk is going to install...
When this binary is replaced my changes will be lost... :-(
(That's a pity but at the moment I do not see another solution...)

Thank you very much


Christian
 
How about this one? I really don't understand people are not complaining about this major issue. In plesk 11 this is still actual. People think they have secured stuff and it's not working as it should!
 
The only reason I can think of is that because no one really uses it like this in combination with FCGI. I know in our hosting we have tens of thousands of clients and over the last 8 years it has never come up.
 
Back
Top