With the generated .htaccess file in the files directory the files in this directory become unaccessible. My webhoster is Strato. The .htaccess initially reads:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

Uncommenting the first line as in

# SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

solves the problem.
I have searched the docs for the meaning of SetHandler and found out that there must be a corresponding Action directive in this .htaccess or in a .htaccess in any upper directory. As it is now, Apache does not know the handler and returns an error (i.e. the required images are not loaded).

My questions are: where is the handler to be used defined? Is it a security issue to do without the SetHandler?

Regards,

Wilfried

CommentFileSizeAuthor
#5 fix_noFileInfo_access.patch1018 bytesschuyler1d
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Pepe Roni’s picture

Sorry, forgot some technical details:

PHP 5.2.2
Apache/1.3.31 (Unix)

wilfried

morphir’s picture

I got a similar issue with my site5.com hosting plan.

subscribing until I've investigated this closer.

drewish’s picture

Category: bug » support

removing that isn't a good idea, see the security advisory it references: http://drupal.org/node/65409

headkit’s picture

even uncommenting the first line doesn't make the files accessible to me.
I try to get the image module showing me some images on strato...

schuyler1d’s picture

Status: Active » Needs review
FileSize
1018 bytes

I get the same error, because my server doesn't have AllowOverride FileInfo turned on (and I don't have access to change that).

This code seems to be cruft left over from the security revision:
http://drupal.org/node/66763

The fix described in DRUPAL-SA-2006-007 seems to be in upload.module, so this part should be removed
and that's what the patch does.

For the initial poster, you can apply the patch, or ask your Apache server admin to give you AllowOverride FileInfo access.

ricabrantes’s picture

any news about this?

schuyler1d’s picture

Category: support » bug

To summarize:
The vulnerability was that uploading files with a '.php' extension, for instance could be uploaded and then run.
1. DRUPAL-SA-2006-006, the original solution, created .htaccess files with SetHandler so php files would not be run.
However!
2. DRUPAL-SA-2006-007 (original text), realized that the .htaccess file crippled all access to the upload directory on apache configurations where SetHandler is not allowed in .htaccess.
3. So, SA-2006-007's fix was INSTEAD to change dangerous extensions so that the prefix gained an '_' like s/.php/._php/g. This removed the requirement for the SetHandler fix.
4. The upload.module does #3, but for some reason the code to create .htaccess files is STILL in drupal core's file.inc.
5. Therefore, the offending code must be removed. (see patch above)

Bart Jansens’s picture

Status: Needs review » Closed (works as designed)

Actually the .htaccess code was left in place because there may already have been files with such dangerous extensions, uploaded in the past. Renaming the files on upload only fixes things for newly uploaded files.

If for some reason your host does not allow you to override these options in .htaccess, you can create an empty .htaccess file in that directory. That will prevent drupal from creating one. But you should read the SAs so that you are aware of the possible security implications. You don't want a quick fix like this and have your site hacked a week later ;)

Note that the problematic filenames aren't things like ".php" because those shouldn't be allowed to be uploaded, but filenames like ".php.txt" which get executed as PHP in many configurations.

arpieb’s picture

Version: 5.1 » 7.x-dev
Status: Closed (works as designed) » Active

Reopening this bad boy as it is still in core for D7 (apparently it was never fixed in D6 either). Since the problematic upload code has long since been fixed, this shouldn't be an issue for D7 installations, right...?

Running into this while trying to publish a third-party-generated flipbook under the sites/default/files directory where the software in question generates a directory tree with index.html at its root level to handle directory browsing. No amount of head- or keyboard-banging can get my .htaccess file in the subdirectory to take hold with the parent directory's flawed .htaccess file.

If uploaded PHP files in that directory structure are the concern, why wasn't a simple Rewrite rule built to invalidate requests with a .php extension instead of intentionally breaking the Apache .htaccess processing chain with an invalid handler...?

Inquiring minds would like to know...

rob.gianfelice@gmail.com’s picture

Hi all.

I'm working with D7.

I have implemented a site and I need to manage images and similar into sites/default/files directory.
I have the same problem with .htaccess: with the autogenerated one, images are not accessible.

I have asked to my web hosting master to update the auto-generated .htaccess commenting two lines of the three and now I got the following file
------
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None
#Options +FollowSymLinks
------
Now it works fine, but the question is: how can I control the process that automatically create the .htacces in a new directory?
I would like to configure drupal to generate the new .htacees with the two comments in order to avoid involvement of my web hosting master.

any suggestions?

Moreover: Could I got some problems with the .htacces file commented?

BR
Roberto

rob.gianfelice@gmail.com’s picture

Sorry.

I'm too novice to drupal ;-)

I found the include file file.inc and I have updated the function file_create_htaccess in according to my web hosting rules and… now it works fine.

Hope this can help others.

Below the udpated function:

/*====================================*/

function file_create_htaccess($directory, $private = TRUE) {
if (file_uri_scheme($directory)) {
$directory = file_stream_wrapper_uri_normalize($directory);
}
else {
$directory = rtrim($directory, '/\\');
}
$htaccess_path = $directory . '/.htaccess';

if (file_exists($htaccess_path)) {
// Short circuit if the .htaccess file already exists.
return;
}

if ($private) {
// Private .htaccess file.
/* $htaccess_lines = "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006\nDeny from all\nOptions None\nOptions +FollowSymLinks"; */
$htaccess_lines = "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006\n#Deny from all\n#Options None\n#Options +FollowSymLinks";
}
else {
// Public .htaccess file.
/* $htaccess_lines = "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006\nOptions None\nOptions +FollowSymLinks"; */
$htaccess_lines = "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006\n#Options None\n#Options +FollowSymLinks";
}

// Write the .htaccess file.
if (file_put_contents($htaccess_path, $htaccess_lines)) {
/* drupal_chmod($htaccess_path, 0444); */
drupal_chmod($htaccess_path, 0707);
}
else {
$variables = array('%directory' => $directory, '!htaccess' => '
' . nl2br(check_plain($htaccess_lines)));
watchdog('security', "Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your %directory directory which contains the following lines: !htaccess", $variables, WATCHDOG_ERROR);
}
}
/*====================================*/

BR
Roberto

marcingy’s picture

Status: Active » Closed (works as designed)

Closing see comment 8.