Bug 741389 (CVE-2011-3730)

Created drupal7 tracking bugs for this issue

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

This indicates 7.0.  We ship 7.8.  Is this relevant?

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.

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

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).

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?

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.

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!

I've filed bug #741958 for the RFE to have a default error log.