CiviCRM 4.4.4 "The CiviCRM debug log should not be downloadable."

[Chris Burgess]

I did, thanks

Please review the updated docs @ http://wiki.civicrm.org/confluence/display/CRMDOC/checkUploadsAreNotAccessible

There are instructions there for identifying if you are seeing a "false positive" (CiviCRM shows a warning when files *are* in fact protected) OR if you are seeing a legitimate warning.

One possibility is that .htaccess rules might be bypassed for the server's IP address - so the request from your server IP is specially treated. That MIGHT cause a false positive. Or there might just be a bug in the check. If so, we'd like to find out what it is ...

[michael23]

Just want to chime to say that I have the same problem as clarkac. I have warnings for both the debug log and upload directory.

Both locations (protected by htaccess) are not accessible via a browser so I believe it is generating a false positive.

[clarkac]

Thanks for posting, Michael23, I appreciate your support! The two directories that I get the messages about are publicly inaccessible.  I have confirmed with my hosting company (vidahost.com) that .htaccess files at the directory level are supported.
Hence I have created  http://issues.civicrm.org/jira/browse/CRM-14210 If there's anything I can do to help debug this, just let me know - I'll do what I can.  FYI, at another hosting site I use - ukfast.com - this problem doesn't exist.  Isn't software just wonderful?

[Chris Burgess]

Mark & Michael (and others) - if you can give more info (here or on CRM-14210) then we can look at this further. You'll need to compare your server logs to see the files which CiviCRM is retrieving that seem to be giving false positives.

For extra points, jump into CRM/Utils/Check/Security.php, modify CHECK_TIMER (number of seconds between repeat of warnings, so you can repeat the test each time you reload), then add some debug code to the check which is failing to see why these checks are returning warnings on your site.

[michael23]

Hi Chris,

A quick look at my server logs reveals the following (in order of latest entry):

/media/civicrm/upload//latest-version-cache.txt 0 2/14/14 8:14 PM PHP/5.3.28
/media/civicrm/upload//latest-version-cache.txt 0 2/14/14 8:14 PM PHP/5.3.28
/media/civicrm/upload//latest-version-cache.txt 0 2/14/14 8:14 PM PHP/5.3.28
/media/civicrm/ConfigAndLog/CiviCRM.68195fa08526034ba3f485163397bafc.log 0 2/14/14 8:14 PM PHP/5.3.28

Hope that helps?

[Chris Burgess]

Please share your access log for the same period - this will show requests which were *successful*, rather than only those which were unsuccessful.

[Chris Burgess]

See http://issues.civicrm.org/jira/browse/CRM-14210 for a patch - thanks Andy for getting this onto the radar and giving us access to debug it.

[davej]

Related to this issue, 4.4.5 has added a check on $config->customFileUploadDir , typically files/civicrm/custom/ . This directory was not mentioned in the security advisory https://civicrm.org/advisory/civi-sa-2014-001-risk-information-disclosure as needing protection and it has up until now been used for purposes requiring files within it to be web-accessible, e.g. contact images, which are served up on the contact summary directly over http(s).

Can you confirm that customFileUploadDir should not be web accessible? Is it a bug that contact images are served up directly over http(s)?

Thanks,

Dave J

[dotsam]

On 4.4.5 (previously running 4.3.7) my contact images no longer load, giving me a 403 access forbidden error. If I delete the .htaccess that is in the /sites/default/files/civicrm/custom directory I am able to view my contact images again. The .htaccess says this:

Code: [Select]

<Files "*">
  Order allow,deny
  Deny from all
</Files>


[dotsam]

Actually, I guess it's better to just allow images, and deny access to everything else (e.g. the csv's):

Code: [Select]

<Files ~ "\.(jpq|jpeg|png|gif)$">
   order deny,allow
   allow from all
</Files>


[Chris Burgess]

@dotsam, that .htaccess change might permit sites to expose contact images again

This is a change in CiviCRM's default behaviour, but I'd argue it's an improvement even though we've had to change systems for one or two client sites on account of it.

CiviCRM deals with contact data for a wide variety of organisations; whether contact data including their image is for public or private consumption is not a given. I think the right thing to do is to protect data by default. For reference, the settings help for the contact image field @ civicrm/admin/setting/path says somethng like,

Path for storing the documents and images attached to the records of contacts (photos, resumes, contracts, etc.). These files are defined using custom fields of type "file".

That doesn't sound like public data to me.

Ultimately, I'd like to see CiviCRM head towards being able to define "public" or "private" per custom file field, as is possible with Drupal. That would make it much clearer and allow sites to handle this with greater flexibility.

[totten]

My favorite idea so far is to include a secure signature in the link to each attached file, e.g.

http://example.com/civicrm/file?fid=123&entity_id=456&ts=1234567890&sig=a1b2c3d4e5f6a7b8c9d0

This removes the problem of "double-implementing" the access control logic: the page-controller decides if it wants to display a link to an image, and we don't need to re-implement that logic as part of "/civicrm/file". This adapts nicely to situations like custom profile-listings and Drupal views where the site-admin makes the decision about which information to disclose to a given user.

Tangentially, it also allows a time-limit on how long one can download attached files.

Such a change would obviously be too big for 4.4.x.

[Viv]

If the web server is nginx, then you might add a configuration like this (untested - b/c I don't have nginx installed):

Code: [Select]

  location ~ ^/sites/.*/files/civicrm/(ConfigAndLog|upload|templates_c) {
    deny all;
  }


Since there will be other NginX users out there wondering about this, I've tested this on a Drupal 7.28 install with CiviCRM 4.4.5 on an Ubuntu server and can confirm that it does work - I just added it to the end of the NginX site configuration file located in the available sites folder. Also as per the changes in 4.4.5 I added the 'custom' folder as well, so the code looked like:

Code: [Select]

    location ~ ^/sites/.*/files/civicrm/(ConfigAndLog|upload|templates_c|custom) {
deny all;
    }
Thanks to Totten for the original info!

[dkretz]

Is it not possible for the installation/upgrade script to install a structure that doesn't, by default, trigger security error messages?

[Chris Burgess]

Is it not possible for the installation/upgrade script to install a structure that doesn't, by default, trigger security error messages?

No, and you probably don't want that.

CiviCRM (an application) should not be able to manipulate settings in the application's hosting environment. If it did, then CiviCRM (or Wordpress, or phpbb2, or ...) can likely hijack other sites on the same server, and so forth.

By making the server configurations writable to the webserver user, one might achieve this ... but it would be a far worse situation than the one where you need an administrator to configure your hosting environment properly. Your website (and others hosted on the same setup) would be pretty smartly eliminated, or put to nefarious work, or ...

EDIT: Where CiviCRM can write .htaccess files, AND Apache permits those access files to overwrite a limited amount of configuration, this is what's happening. Nginx have made an architectural decision not to do that, which means no .htaccess for Nginx users (for performance and other reasons documented on their site).

Regardless of the hosting environment, CiviCRM sites dealing with peoples private data require the skills (legal, technical, ...) to handle that data. (We understand that most NGOs are not massively cashed up, but they still need to be responsible!)