Drupal, probably 5.10 and 6.4, does not set the secure flag for the session cookie in an https session, which can cause the cookie to be sent in http requests and make it easier for remote attackers to capture this cookie. http://int21.de/cve/CVE-2008-3661-drupal.html http://www.securityfocus.com/bid/31285
Created drupal tracking bugs for this issue CVE-2008-3661 Affects: F8 [bug #464163] CVE-2008-3661 Affects: F9 [bug #464164] CVE-2008-3661 Affects: Fdevel [bug #464165] CVE-2008-3661 Affects: epel-4 [bug #464166] CVE-2008-3661 Affects: epel-5 [bug #464167]
Filed critical upstream bug: http://drupal.org/node/315703
Comment on upstream bug: >Damien Tournoud - October 1, 2008 - 12:32 >Priority: critical » normal >Status: active » by design > >First, security issues should not be filled in the public issue tracker, following >our security guidelines. > >Second, we consider that this is a configuration problem. It's your >responsibility to set session.cookie_secure in the SSL virtual host if you want >an SSL-only website. Given this, and the fact that no fix is forthcoming, and that there's no elegant way to patch for this, I suggest that I add a note on this to the fedora-README and close. Thoughts?
This sounds reasonable to me.
I'm going to recommend in the README that SSL sites set the SSLRequireSSL directive in the /etc/httpd/conf.d/drupal.conf, and put it in there, commented out. Sufficient?
Unless I'm missing anything, this issue is mostly significant in cases when some non-https web application is run on the same vhost as drupal (squirrelmail | gallery | mantis - other applications mentioned by the same reporter). If drupal does not contain any explicit https -> http redirect / reference, SSLRequireSSL probably won't help much. Looking into includes/session.inc, drupal does not restrict cookie usage to some vhost / directory. So if other non-https web app on the same vhost is accessed over non-https connection, drupal cookie may be sent unsecured. Attacker can possibly trick victim to visit such non-https URL, e.g. http://my.host/drupal . If victim follows such link, this happens: - http request is set, which contains drupal cookie; as session is not SSL-secured, attacker can possibly sniff cookie on the wire - server notices that https is not used and refuses access (due to SSLRequireSSL), but it's already too late, as attacker already has victim's cookie - attacker uses sniffed cookie over SSL connection Upstream suggestion seems to be to set php_flag session.cookie_secure on in httpd configuration, rather than SSLRequireSSL. As for the way this issue got reported - this bug was opened when CVE id was assigned publicly. There's not much point in having public issue tracked via private bug. Actually, the very same issue was reported in the drupal bug tracking system long ago: http://drupal.org/node/66970 and other related upstream bug: http://drupal.org/node/170310
So essentially s/SSLRequireSSL/php_flag session.cookie_secure on/, more or less? I agree about the bug handling. I filed it publicly out of ignorance of the drupal.org reporting system, but it was already public.
drupal-6.5-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
drupal-5.11-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
This has been fully corrected in all current drupal packages.