Tags:
create new tag
, view all tags

Question

in the pub/.htaccess I add the line "php_flag engine off" and then whenever I view pages, they are broken (no images and incorrect fonts etc are displayed). I do have PHP 4.4.4 and 5.2.0 installed, so it should work.

Without being able to disable php inside code, I am loathe to release my TWiki to the public, as I suspect it would be too insecure. This would render my last week of work somewhat useless. Ouch.

I did some research:

  1. "php_flag engine off" is appropriate in .htaccess, according to http://www.php.net/manual/en/ref.apache.php.
  2. I also tried "php_value engine off", which produced the same problems. "php_value engine off" is acknowledged as working in http://wiki.mozilla.org/Documentation:Security , but in fact, should not be used for booleans according to http://www.php.net/manual/en/configuration.changes.php#configuration.changes.apache.
  3. "php_admin_flag engine off" produced the same problems, which is not surprising, as http://www.php.net/manual/en/configuration.changes.php#configuration.changes.apache says it cannot be used in .htaccess files - it is designed for .conf files. In addittion "Any directive type set with php_admin_flag can not be overridden by .htaccess or virtualhost directives."

I am installing on a hosted service (1and1) so I cannot edit the http.conf. However, I can view the http.conf in the folder above, and have confirmed it does not include "php_admin_flag engine off", so unless it is higher up the tree, I still don't know why I have a problem.

Also, due to being on 1and1, I cannot access the Apache error logs, which makes things a bit harder.

Thanks

Environment

TWiki version: TWikiRelease04x00x05
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS: Debian
Web server: Apache 1.3.29
Perl version: Perl 5.6.1
Client OS: XP SP2
Web Browser: FFox 1.5.0.9
Categories: Htaccess

-- EricWoods - 05 Feb 2007

Answer

ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

According to http://faq.1and1.com//scripting_languages_supported/php/14.html there are two ways php can be run:

  1. running PHP as a CGI
  2. running PHP as an Apache Module
It appears that the shared hosting plan I am on is running PHP as a CGI. For this method, it only suggests turning the php engine off by creating a php.ini in the same directory as the .htaccess and adding a directive there (I think it is "engine off", but it could be "engine = off" - I have not been able to confirm either way).

I tried it - it seems to work, though I have not been able to try hacking my own site.

I don't know why the .htaccess method doesn't work, but I guess the .htaccess should be edited to add a comment like: # if you run PHP as a CGI (as is the case with some hosted servers) then do not use this flag. Instead, create a php.ini file in the same folder and add the line "engine off".

Actually, come to think of it, the php.ini technique also works for running PHP as an Apache Module, so maybe this php.ini file should just be added to the pub folder by default in your release?

-- EricWoods - 06 Feb 2007

It is highly unusual to run php as CGI these days so your shared host is really a museum of an installation.

The thing for you to check is: is PHP enabled at all? If not you have nothing to protect

Using ftp you can upload a file called tryme.php (or if your host is as old as I think tryme.php3 or tryme.phtm). Try all 3.

In the file you make a simple PHP program.

<? phpinfo(); ?>

Yes. One line. If you see the raw line then you are safe. If you see a very advanced output showing all sorts of settings then you can end up that someone uploads an attachment which is a PHP program and activate it with their browser and this is as good as having a command line prompt. And this is a situation you do not want.

-- KennethLavrsen - 06 Feb 2007

Hi Keith. Not so sure about the 'museum' comment. Probably more because the host provides virtual hosts (that need to able to be controlled?), or because is has so many customers, that changin over would be a logistcal nightmare. 1and1 is a very popular host, and as such, there are bound to be many potential users of TWiki that use them, including myself and BryceSchober who even wrote a detailed TWikiOnWebHost1and1 (that didn't cover this topic). So please don't underestimate the frequency of my situation, or consider it not worth adding line in the .htaccess template. It is an equally possible scenario that you haven't heard from many of these users because TWiki is so hard to install that they have run away screaming. I don't mean to insult, but I do mean to humble you, because your comment came across as a little eliteist. I really appreciate your help, and think TWiki is great, but I have had a really hard time installing and securing it, with more than one person who has suggested I give up (an others who have given up). My ultimate goal is not only to get it running and secure, but also to make the experience easier for others who follow.

Anyway, on with the topic at hand. Thanks for the hack test. I gave it a go. I confirmed what I said at the start of the page - I have PHP 3.x, PHP 4.4.4 and 5.2.0 enabled, and the page request showed a whole bunch of info.

The interesting think is that adding a php.ini with either "engine off" or "engine = off". Does not change anything. However, enabling the .htaccess file and the line "AddType text/plain .html .htm .shtml .php .php3 .phtml .phtm .pl .py .cgi" does work - only the one line of text is shown.

So this raises the questions:

  1. Am I secure with just having the "AddType" line? The .htaccess template suggests that you should also turn off the php engine to be safe. Maybe people can use other file extensions, or embed that code in other types of files? I don't know enough to say.
  2. If I should have both security measures, how can I get the php engine turned off? http://builder.com.com/5100-6371-5268948.html suggests "engine = off" is the right syntax...
  3. According to http://nz2.php.net/apache the "engine" name was only available since PHP 4.0.5, so I guess editing php.ini will still not turn of the PHP3 engine?

-- EricWoods - 07 Feb 2007

Maybe it does not work because, according to http://www.php.net/manual/en/ini.php "In order for these settings to work in your htaccess file, you will need to add "Options" to your AllowOverride specifications for the directory/webserver if it's not already allowed". I can't figure out if that means it has to be in a .conf file (which I can't do), or what the line should be (has "Options None" got anything to do with it?).

-- EricWoods - 07 Feb 2007

The museum remark was a message to 1and1. I am sure they read this also. If they get insulted - fine. I was not intending to insult their customers (you).

I am committed to help getting TWiki working on as many OSes and combinations as possible and helping you getting TWiki working in a safe way.

I am nervous about not having the php engine turned off inside pub.

Try making a file called tryme.php.txt and tryme.php.museum. I am not sure how Apache works with PHP in the CGI situation so please try this and see if the AddType does the job.

The AllowOverride sets whether you are allowed to override specific settings at lower level .htaccess files. If 1and1 has defined an AllowOverwide that prevents you from doing much inside .htaccess files then you need to contact 1and1.

That said I think the problem with disabling PHP when it is setup as CGI is very different from setting it up as a module. When PHP is a module it sees all the directives inside apache.conf and .htaccess. Then PHP is not a module Apache will see the php directive as invalid and completely ignore the .htaccess file which is why TWiki will not work at all with the directives.

When PHP is working with CGI then Apache is in reality starting a program called php which then parse the php program. So we need to stop Apache from invoking any kind of CGI inside pub.

typical setting to setup php as CGI involves settings like

ScriptAlias /php-cgi /usr/local/php-cgi/bin/
Action php-cgi /php-cgi/php
AddHandler php-cgi .php .php4 .php5

So we need to somehow neutralize these settings inside pub so that pub becomes a dead zone with no sort of CGI active.

So we may want to try with some settings like these for pub

SetHandler None

And maybe set some of the other settings to point to nothing. It is difficult to say what you need to do because there are so many ways to setup scripting in Apache so it depends on how your host have setup things.

-- KennethLavrsen - 07 Feb 2007

Awsome help thanks. phptest.php, phptest.php.txt and phptest.php.museum all do not execute - they only show the one line of text, which is good.

I can view the httpd.conf file in the parent directory of my virtual host. I cannot see any mention of AllowOverride in it. This conf also has ScriptAlias settings within each "<VirtualHost ..." definition (one for each domain and each subdomain). However, they all seem to have paths that don't exist (I don't want to be too specific in a public forum). No mentions of Action or AddHandler.

I have searched up all the parent trees up to the root directory, and no other .conf files seem to exist.

And when I comment out "AddType..." and use "SetHandler None", then all php scripts (even xxx.museum) can execute.

Many Thanks

-- EricWoods - 10 Feb 2007

looks like this was answered.

-- CrawfordCurrie - 10 Feb 2007

Actually, I'm afraid that my questions have not been answered. But perhaps that was my fault, so I'll re-cap.

At present, turning off the php engine in either .htaccess ot php.ini does not work. Using an "AddType..." line in the .htaccess file does prevent php from executing, but to quote Kenneth "I am nervous about not having the php engine turned off inside pub".

Part of the reason is that the shared hosting plan I am on is running PHP as a CGI (instead of as an Apache Module which most people have). When running PHP as a CGI, I only found mention of turning the php engine off by creating a php.ini, however the text to put into the php.ini was vague, and I am not sure I got it right. This still doesn't tell me if the "php_admin_flag engine off" in .htaccess should work in my situation.

So if I ignore the .htaccess file and focus on the php.ini file, there are 2 possible reasons it is not working: 1) I have not added the right text to the file (and I can't find an exact example of the text I should add). 2) My server is not configured to allow the engine to be turned off.

Regarding 2), I may have traced the problem to this quote from http://www.php.net/manual/en/ini.php "In order for these settings to work in your htaccess file, you will need to add "Options" to your AllowOverride specifications for the directory/webserver if it's not already allowed". Maybe this also applies to php.ini?

However, I can't figure out if that means it has to be in a .conf file (which I can't do), or what the line should be (has "Options None" got anything to do with it?). I can see that there is only one .conf file in all of the parent folders (httpd.conf file in the parent directory of my virtual host), and this never uses the terms AllowOverride, Action or AddHandler, but it does have "ScriptAlias /cgi-bin/ /directorypath/" settings within each "<VirtualHost ..." definition (one for each domain and each subdomain). However, they all define directorypath that don't exist - they are a directory path that does exist, with a "/cgi-bin/" subdirectory on the end that doesn't exist.

So the 3 questions I asked earlier still stand unanswered:

  1. Am I secure with just having the "AddType" line? The .htaccess template suggests that you should also turn off the php engine to be safe. Maybe people can use other file extensions, or embed that code in other types of files? I don't know enough to say.
  2. If I should have both security measures, how can I get the php engine turned off?
  3. According to http://nz2.php.net/apache the "engine" name was only available since PHP 4.0.5, so I guess editing php.ini will still not turn of the PHP3 engine?
Plus:
  1. What line do you put in the php.ini to turn off the php engine? http://builder.com.com/5100-6371-5268948.html suggests "engine = off" is the right syntax, but it didn;t work for me.
  2. How do I "add 'Options' to your AllowOverride specifications for the directory/webserver if it's not already allowed"? Can this be done in an .htaccess file? Looking at the info above, for more info.

Yikes - quite a hairy situation, but I have tried to simplify it as much as possible. Thanks for any help anyone might be able to offer.

-- EricWoods - 21 Feb 2007

I had a very similar problem. If I copied pub-htaccess.txt to pub/.htaccess, my page would render poorly - not icons, no styles. If I removed pub/.htaccess it would look fine. I thought the problem was with the "php_flag engine off" but it turned out to be the "Options None" directive that was above it. I commented that out and everything works fine. I believe I'm still protected by the .htaccess in twiki root which has the "Options -Index" directive that would apply to the subdirectories as well.

-- TWikiGuest - 16 Mar 2007

Dreamhost is a fairly popular web host, used for some TWiki sites, and provides the option of running PHP as CGI or an Apache module - use of CGI is recommended for security.

-- RichardDonkin - 17 Mar 2007

What has been happening since March of 2007 that no one is having a problem with this? Nearly a year later, and I am having the identical problems as EricWoods. Unlike TWikiGuest on 16 Mar 2007, I find I have to disable BOTH "Options None" and "php_flag engine off" to get pages to render correctly. Is there some conclusive solution to this problem that hasn't been amended to this topic?

-- TedHenigson - 14 Jan 2008

I am having this problem as well with the latest and greatest version as of 2/2/08 4.2.0 . I am running at csoft.net which also executes PHP as CGI (Guess this is not so uncommen)

-- RickGuardia - 02 Feb 2008

Nothing has happened. It slipped off the radar screen.

I have created a bug report with urgent status so we get this addressed in 4.2.1. I have assigned the bug to myself.

I will need help for confirming the fix so please come back to this topic often the next days.

-- KennethLavrsen - 03 Feb 2008

It is a bit odd that you had to turn options off to get the pub directory to work.

The options directive is a very important directive when it comes to protecting a directory to which an attacker can upload files.

Here is a short summary of the values you can use with Options and what they do.

  • None: option can be set to None, in which case none of the extra features are enabled, or one or more of the following:
  • All: All options except for MultiViews. This is the default setting.
  • ExecCGI: Execution of CGI scripts using mod_cgi is permitted.
  • FollowSymLinks: The server will follow symbolic links in this directory.
  • Includes: Server-side includes provided by mod_include are permitted.
  • IncludesNOEXEC: Server-side includes are permitted, but the #exec cmd and #exec cgi are disabled. It is still possible to #include virtual CGI scripts from ScriptAliased directories.
  • Indexes: If a URL which maps to a directory is requested, and there is no DirectoryIndex (e.g., index.html) in that directory, then mod_autoindex will return a formatted listing of the directory.
  • MultiViews: Content negotiated "MultiViews" are allowed using mod_negotiation.
  • SymLinksIfOwnerMatch: The server will only follow symbolic links for which the target file or directory is owned by the same user id as the link.

Options can be added and removed by placing a + or - in front of the value. You have to take care when using the + and - syntax because that means you need to have the overview of the settings defined at a higher level .htaccess or in the Apache config files. Note that mixing Options with a + or - with those without is not valid syntax, and is likely to cause unexpected results.

The directives that are really dangerous are ExecCGI, Includes, and IncludesNOEXEC because these enables an attacker to upload a script and run it. It is so easy an attack that it makes you ill just thinking about it.

If you have used symbolic links inside the pub directory then the Options None gives a problem. But then you can use Options FollowSymlinks or the safer SymLinksIfOwnerMatch which may require access to changing ownership of files, links and directories.

Those of you that had success by removing the Options None statement could help me analysing the problem by experimenting with which option that has to be enabled in the pub/.htaccess file.

-- KennethLavrsen - 03 Feb 2008

I would be happy to help, but I need some more info (not a .htaccess expert). Here is where I am: 1) I had to remove the "php_flag engine off" line from .htaccess as it was causing broken images etc . 2) I tried adding php.ini to the same directory with engine off line. This had no effect. 3) I added a ../pub/phpversion.php to my site so I could test.

I have a trial account a csoft setup to test this (I want it working before I commit). You can see the php version at: http://guardia.trial.csoft.net/twiki/pub/phpversion.php

If you give me example line entires for .htaccess, I can give it a try.

-- RickGuardia - 11 Feb 2008

I sent this problem to support at my web hosting company and this is the response I got (will try it later). I wanted to get feedback on thier suggestion.

****** Those instructions are incorrect. The "php_flag" directive in .htaccess files will not work unless the web server is using mod_php. If you want to turn off scripting in a directory, use the following:

RemoveHandler .php .php3 .phtml .cgi .fcgi .pl .fpl .shtml

But this whole procedure sounds dubious. Our servers execute PHP in a secure manner (that is under your own UID), so directories used by PHP scripts can use permission modes of 0700, and files can use modes as secure as 0600.

Those instructions probably apply only to typical shared servers where you would have to worry about world-write permissions such as 0777 on directories. *********

-- RickGuardia - 12 Feb 2008

It is not dubious.

If I can attach a php program to a topic and then view it = run it then only fantasy is the limit how I can abuse that no matter what the file access rights are. If TWiki can save a file then the php program can do the same to any file in the twiki tree and add all sorts of funny applications like turning your server into a file sharing site for porn.

The RemoveHandler directive seems like a good solution for sites running PHP as CGI. Thanks for that advice.

Will add that to generic example .htaccess

-- KennethLavrsen - 26 Mar 2008

Closing this question after more than 30 days of inactivity. Feel free to re-open if needed.

-- PeterThoeny - 01 May 2008

Change status to:
Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r21 - 2008-05-01 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.