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
Comment | File | Size | Author |
---|---|---|---|
#5 | fix_noFileInfo_access.patch | 1018 bytes | schuyler1d |
Comments
Comment #1
Pepe Roni CreditAttribution: Pepe Roni commentedSorry, forgot some technical details:
PHP 5.2.2
Apache/1.3.31 (Unix)
wilfried
Comment #2
morphir CreditAttribution: morphir commentedI got a similar issue with my site5.com hosting plan.
subscribing until I've investigated this closer.
Comment #3
drewish CreditAttribution: drewish commentedremoving that isn't a good idea, see the security advisory it references: http://drupal.org/node/65409
Comment #4
headkit CreditAttribution: headkit commentedeven 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...
Comment #5
schuyler1d CreditAttribution: schuyler1d commentedI 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.
Comment #6
ricabrantes CreditAttribution: ricabrantes commentedany news about this?
Comment #7
schuyler1d CreditAttribution: schuyler1d commentedTo 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)
Comment #8
Bart Jansens CreditAttribution: Bart Jansens commentedActually 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.
Comment #9
arpieb CreditAttribution: arpieb commentedReopening 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...
Comment #10
rob.gianfelice@gmail.com CreditAttribution: rob.gianfelice@gmail.com commentedHi 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
Comment #11
rob.gianfelice@gmail.com CreditAttribution: rob.gianfelice@gmail.com commentedSorry.
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
Comment #12
marcingy CreditAttribution: marcingy commentedClosing see comment 8.