[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201404012014.s31KEAsG023252@linus.mitre.org>
Date: Tue, 1 Apr 2014 16:14:10 -0400 (EDT)
From: cve-assign@...re.org
To: csteipp@...imedia.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: MediaWiki 1.22.5 login csrf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The CVE project currently accepts vulnerability reports that are
associated with the "Login CSRF" concept, e.g.,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1491
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.,
https://bugzilla.wikimedia.org/show_bug.cgi?id=62497
"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:
http://openwall.com/lists/oss-security/2014/03/28/10
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
carefully.
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 http://www.youtube.com/login 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.
Thus:
-- 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTOx0bAAoJEKllVAevmvms7xcIALUV3/0TSvj2E/f6zXZPy0LL
j7lZdVKTBfYw3G8HVeJtf3zjXmA7ejEXFf1CYGmGKaj6QEZIkHubtfzNqoW+H8IN
a35S3xACz3p0F+ogQ094eJAGzRWoeP2FjPj9fhHPp97s/ORz8Fm9Au6L26ZXIyjb
2my+ehLPpWpsJdQCXaoqE4hwhmkxXIU+JTs8iTAVEEMSql/AQQIloR6/Ac/KC/m3
yPkYQiIwSUBEdoQnrQjpz6XFSC1Q48a0Wo1YPNQDDbMhPo/jVB1/tUasHuvXjO2b
PfOaWVnQsNLcMoZCf7VoheeXJVtN6rjP4L4tuP3wl5HfM6vjC5bKg9+8JftJw9E=
=jKat
-----END PGP SIGNATURE-----
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.
