Red Hat Bugzilla – Bug 464162
CVE-2008-3661 drupal session hijacking
Last modified: 2009-07-08 17:31:32 EDT
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.
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:
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.
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:
and other related upstream bug:
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.