Bug 741389 (CVE-2011-3730) - CVE-2011-3730 drupal7: installation path disclosure via a direct request to a .php file
Summary: CVE-2011-3730 drupal7: installation path disclosure via a direct request to a...
Alias: CVE-2011-3730
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 741391 741392 741393
TreeView+ depends on / blocked
Reported: 2011-09-26 17:53 UTC by Vincent Danen
Modified: 2019-09-29 12:47 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-08-22 15:25:43 UTC

Attachments (Terms of Use)

Description Vincent Danen 2011-09-26 17:53:20 UTC
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 17:55:26 UTC
Created drupal7 tracking bugs for this issue

Affects: fedora-all [bug 741391]
Affects: epel-6 [bug 741392]
Affects: epel-5 [bug 741393]

Comment 2 Gwyn Ciesla 2011-09-27 00:43:25 UTC
This indicates 7.0.  We ship 7.8.  Is this relevant?

Comment 3 Vincent Danen 2011-09-27 04:36:00 UTC
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 14:10:46 UTC

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 15:51:33 UTC
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 17:49:38 UTC
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 Gwyn Ciesla 2011-09-27 18:03:03 UTC
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 15:23:31 UTC
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".


Comment 9 Vincent Danen 2011-09-28 15:40:03 UTC
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.