oss-sec mailing list archives
Re: CVE request: MediaWiki 1.22.5 login csrf
From: Chris Steipp <csteipp () wikimedia org>
Date: Fri, 28 Mar 2014 08:33:38 -0700
On Mar 28, 2014 7:54 AM, "Florent Daigniere" < florent.daigniere () trustmatta com> wrote:
Sorry to be thick here but it still doesn't make any sense to me... The session-id should be renewed upon login AND any credential/privilege change (that includes password changes). This protects against session fixation attacks (where the attacker coerce a user into using a session he controls). On these pages, there's usually no need for anti-CSRF protection as they tend to require credentials (something the attacker, by definition, doesn't have).
Slightly different attack. The attacker (who knows their own password and chooses the reset-to password) was able to cause a logged out user (victim) to login with the attacker's account via the change password form. This attack is somewhat specific to mediawiki since we allow users to define JavaScript that will be loaded on pages they visit while logged in... So the victim in this case would run the attacker's personal JavaScript.
Are you saying that Mediawiki has a logic bug (some form of authorization bypass) allowing any authenticated user to change someone else's credentials without knowing them? If so, it's a different category of bug and there again, the control is unlikely to be "adding an anti-CSRF token". Florent PS: While we're at it: yes you should be comparing anti-CSRF tokens in constant-time, unlike what https://bugzilla.wikimedia.org/show_bug.cgi?id=62497#c13 is suggesting. On Fri, 2014-03-28 at 07:19 -0700, Chris Steipp wrote:The session-id is renewed when the user successfully logs in with a password reset. The issue that we patched was that the anti-CSRF token
for
non-authenticated users on the password change form was guessable, and would remain that way even if we regenerated the user's session-id each time they accessed the password rest / login form. On Fri, Mar 28, 2014 at 2:23 AM, Florent Daigniere < florent.daigniere () trustmatta com> wrote:On Thu, 2014-03-27 at 18:37 -0700, Chris Steipp wrote:Hi, we just patched a login CSRF in MediaWiki today. An attacker
could
login a victim as the attacker. Can we get a cve assigned for this? Patch:
https://gerrit.wikimedia.org/r/#/c/121517/1/includes/specials/SpecialChangePassword.php
Release announcement:
http://lists.wikimedia.org/pipermail/mediawiki-announce/2014-March/000145.html
Wikimedia bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=62497That looks like a session-fixation bug to me; not a CSRF... and therefore it's the wrong control: the session-id should be "renewed", that's all. Florent
Current thread:
- CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 27)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Jann Horn (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 29)
- Re: CVE request: MediaWiki 1.22.5 login csrf Jann Horn (Mar 29)
- Re: CVE request: MediaWiki 1.22.5 login csrf Chris Steipp (Mar 28)
- Re: CVE request: MediaWiki 1.22.5 login csrf Florent Daigniere (Mar 28)