Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 1 Apr 2014 16:14:10 -0400 (EDT)
Subject: Re: CVE request: MediaWiki 1.22.5 login csrf

Hash: SHA1

The CVE project currently accepts vulnerability reports that are
associated with the "Login CSRF" concept, e.g.,

Inclusion of these issues is not specific to MediaWiki, nor is it
specific to situations in which arbitrary attacker-authored code
executes immediately upon login.

It is understood that "Login CSRF" attacks are not a subcategory of
CSRF attacks under standard definitions of what "CSRF" means. In other
words, the terminology is perhaps anomalous.

For the original MediaWiki vulnerability report, i.e.,
  "user can be logged into the attackers account, without knowledge of
  user. So attacker can track the user activity."

use CVE-2014-2665.

A separate topic is responding to:
  Why do you call that a vulnerability again?
  The attacker forfeits his credentials; the target ends up logged in as
  the attacker with a session the attacker has no control over... and the
  user is made aware (through the UI) that he's logged in as someone else.
  No trust boundary breached -> no vulnerability.
  After "forced logouts" welcome "forced logins" ;)

MITRE happens to have internal documentation of the Login CSRF concept
because it was needed last year in completely unrelated circumstances.
We'll include it here because it might be generally useful to someone
(... except that it's much too long). The documentation mentions a
YouTube issue that was fixed years ago. We are just sending it as-is:

In the most common definition, "login CSRF" is never about the
attacker forcing the victim to login to the victim's account. "login
CSRF" is always about the attacker forcing the victim to login to the
attacker's account. The original attack was against YouTube, so I'll
try to explain it in the YouTube context. Obviously, for CVE
inclusion, the issue would have to exist in a distributable product
that has the same functionality and behavior as YouTube.

The goal of the attacker is to determine what videos the victim
watches on YouTube. This information is not public, and the victim
would often be unwilling to share it. The threat model is that the
attacker can entice the victim into visiting a web page, but the
attacker has no way to monitor the victim's network traffic or
workstation, and the attacker has no way to obtain the password for
the victim's YouTube account. The threat model also requires that the
victim logs into YouTube intermittently (i.e., does not remain
continuously logged in).

One key aspect of YouTube is that much of the functionality is almost
exactly the same regardless of whether a user is logged in, or not
logged in. Videos requiring authentication for viewing are uncommon.
Also, at least in many YouTube codebases in the past, the existence of
a login was not obvious. A user could see his YouTube username in
small print in the upper right, but would not normally look there

Suppose the victim's YouTube username is VICTIM. The attacker creates
a similar-looking account such as V1CTIM. The attacker obviously knows
the password for this new V1CTIM account. Then, the attacker launches
a login CSRF attack to force the victim's web browser to send a
request to something like with the
parameters username=V1CTIM and password=PASSWORD. Note that this does
not mean that the attacker knows the password for the VICTIM account.

Whenever the victim next chooses to watch YouTube videos, he will be
doing so in the context of an authenticated session under the username
V1CTIM. This session does not last forever. After the session ends,
the attacker can login to the V1CTIM account and use a feature such as
"History > Watched Videos" to see exactly what the victim had watched.


  -- there is a security impact (a leak of private information)

  -- the impact does cross privilege boundaries with respect
     to people even though it does not cross privilege boundaries with
     respect to accounts. As a person, the attacker now has access to
     private information, and the attacker would not have had that
     access without the login CSRF flaw in place.

  -- the security issue is one that can be fixed (within web
     applications, the available approaches for eliminating a login
     CSRF vulnerability are quite similar to the available approaches
     for eliminating other CSRF vulnerabilities)

  -- there is no way to simplify the attack by using a direct-request
     approach instead of a CSRF approach. The attacker cannot obtain
     the private information by establishing his own login session to
     a YouTube account that he controls.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.