Bug 889289 (CVE-2012-5868)

Summary:	CVE-2012-5868 wordpress: session cookie not invalidated on explicit logout
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	fedora, gwync
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-10 10:59:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	889290, 889291
Bug Blocks:

Description Vincent Danen 2012-12-20 17:24:23 UTC

It was reported [1] that Wordpress 3.4.2 (and possibly other versions) did not invalidate a user's session when they explicitly logged out.  Wordpress would clear the cookies in the user's browser, but it failed to invalidate the session cookie within Wordpress itself.  This could allow a malicious user to take a previously-authenticated user's session cookie (wordpress_sec) and add that cookie to a request for the administration interface, which would allow them to access it with the same privileges as the original valid user.

Wordpress 3.5 may also be affected by this, as based on their security categories [2] 3.5 did not contain any security fixes.

[1] http://seclists.org/fulldisclosure/2012/Dec/180
[2] http://wordpress.org/news/category/security/

Comment 1 Vincent Danen 2012-12-20 17:26:12 UTC

Created wordpress tracking bugs for this issue

Affects: fedora-all [bug 889290]
Affects: epel-all [bug 889291]

Comment 2 Vincent Danen 2013-07-24 18:06:41 UTC

Debian got in touch with upstream and this was their reply [1]:

"""
WordPress does not have session management on the server-side. Currently:
* Cookies are only valid as long as they were originally designed to
expire. They may be replayed until they timeout.
* They are hashed so they cannot be used after their original intended
expiration.
* In general one should be using the WordPress admin over SSL if leaking a
cookie is a concern: http://codex.wordpress.org/Administration_Over_SSL.

WordPress takes sensible precautions with these cookies:
* When running over SSL WordPress ensures to set secure flag on cookies
* It sets the HTTPOnly flag so that they are not accessible by javascript
* It invalidates the cookies in the browser.

We are looking into some potential changes to our authentication system to
allow for explicit session termination, but do not have a timeline at this
time.
"""

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696868#37

Upstream leaves the logout functionality entirely in the clients' hands. Arguably, this is not a flaw since the premise of the flaw is that the "session cookie is not being invalidated on the server", but the server has no notion of the session cookie other than "has it expired / is it valid" and relies on the browser to do the "logout". The server certainly doesn't keep track of the cookies/sessions.

If an attacker gets that cookie, and it hasn't expired, yes, it would give them access. Using SSL is a very reasonable workaround.

Comment 3 Product Security DevOps Team 2019-06-10 10:59:47 UTC

This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.