Bug 741389 - (CVE-2011-3730) CVE-2011-3730 drupal7: installation path disclosure via a direct request to a .php file
CVE-2011-3730 drupal7: installation path disclosure via a direct request to a...
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20110130,reported=2...
: Security
Depends On: 741391 741392 741393
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-26 13:53 EDT by Vincent Danen
Modified: 2015-08-22 11:25 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-22 11:25:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2011-09-26 13:53:20 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-3730 to
the following vulnerability:

Name: CVE-2011-3730
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3730
Assigned: 20110923
Reference: http://www.openwall.com/lists/oss-security/2011/06/27/6
Reference: http://code.google.com/p/inspathx/source/browse/trunk/paths_vuln/%21_README
Reference: http://code.google.com/p/inspathx/source/browse/trunk/paths_vuln/drupal-7.0

Drupal 7.0 allows remote attackers to obtain sensitive information via
a direct request to a .php file, which reveals the installation pathin an error message, as demonstrated by
modules/simpletest/tests/upgrade/drupal-6.upload.database.php and
certain other files.
Comment 1 Vincent Danen 2011-09-26 13:55:26 EDT
Created drupal7 tracking bugs for this issue

Affects: fedora-all [bug 741391]
Affects: epel-6 [bug 741392]
Affects: epel-5 [bug 741393]
Comment 2 Jon Ciesla 2011-09-26 20:43:25 EDT
This indicates 7.0.  We ship 7.8.  Is this relevant?
Comment 3 Vincent Danen 2011-09-27 00:36:00 EDT
My understanding is this has not been fixed, but there were a whole bunch of these assigned recently so it is possible that the flaw was originally found against 7.0, and I have no idea whether or not upstream was ever informed.  As far as I know, it is still relevant, but I have not had the opportunity to look at the code to make a real determination.
Comment 4 Paul W. Frields 2011-09-27 10:10:46 EDT
http://code.google.com/p/inspathx/source/browse/trunk/paths_vuln/!_README

Upstream is highly unlikely to fix this issue by implementing strict parameter checking everywhere, AIUI.  This could be addressed with the PHP setting display_errors=Off, which is recommended for production sites anyway.  I wonder how many other xmlrpc-enabled or other Web apps we have that have the same problems.

If we decide to handle, my suggestion would be adding the following in the <Directory> section of the Apache drupal7.conf file we ship:

  # Note, this overrides whatever is in /etc/php.ini --
  # change to "on" if you need to enable debugging.
  # Q.v.: CVE-2011-3730
  php_value display_errors off
Comment 5 Vincent Danen 2011-09-27 11:51:33 EDT
Hmmm... we could do that, and that is a good point.  Looking at the default RHEL6 php.ini, display_errors is Off.  Likewise with Fedora 15.

I wonder if we should just resolve all of these as NOTABUG -- if display_errors is Off by default, then the problem will only occur if a user enables them, which php.ini clearly says is a bad idea in production:


 This directive controls whether or not and where PHP will output errors,
; notices and warnings too. Error output is very useful during development, but
; it could be very dangerous in production environments. Depending on the code
; which is triggering the error, sensitive information could potentially leak
; out of your application such as database usernames and passwords or worse.
; It's recommended that errors be logged on production servers rather than
; having the errors sent to STDOUT.


Perhaps we should instead set error_log to something by default rather than to nothing (either some file in /var/log/httpd/ or to syslog), with a log rotation script, etc.  That would be an argument for the PHP package, however.

We could do it this way, but then we should likely do it for _all_ PHP applications we ship, which seems silly since we have the global default.

(I know this relates to more than just Drupal here, but a bunch of CVEs were assigned for these types of flaws... and while the code itself isn't fixed, out of the box we're not technically affected by any of these and what an administrator/user does afterwards we can't really be responsible for).
Comment 6 Paul W. Frields 2011-09-27 13:49:38 EDT
I wasn't sure what the php.ini default was out of the box, so thanks for checking Vincent.  I would consider this a NOTABUG for drupal7 itself for that reason, then.  (I.e. you break it, you get to keep both pieces.)

But I like your idea of setting a globally safe default in PHP.  Speaking as someone who's dabbled in debugging a PHP app (Drupal in this case!) it would be really useful to see PHP errors going somewhere reasonably discoverable by default, like /var/log/httpd or /var/log/php-something-or-other.  Do you want to file a bug against php and see if the maintainer agrees?
Comment 7 Jon Ciesla 2011-09-27 14:03:03 EDT
I had this conversation about 5 years ago.  I'd written a PHP app, on Fedora, I'd open-sourced it, and this guy was complaining about all these errors dumped to his browser, and how it was really irresponsible of me to have that happen from a security perspective.  I fixed the errors, and reminded him that he'd set that setting, not me. :)

If the default for PHP is secure, I say close them all.
Comment 8 Vincent Danen 2011-09-28 11:23:31 EDT
Paul, yes I'll file an RFE for that.  I do that myself and it makes life much simpler.

Jon, totally makes sense and I'm inclined to agree.  I will close them all this afternoon with an explanation as to how we are secure "out of the box".

Thanks!
Comment 9 Vincent Danen 2011-09-28 11:40:03 EDT
I've filed bug #741958 for the RFE to have a default error log.

Note You need to log in before you can comment on or make changes to this bug.