Re: CVE request: MediaWiki 1.22.5 login csrf

[Florent Daigniere <florent.daigniere () trustmatta com>]

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).

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=62497
> >
> >
> > That 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

Attachment: signature.asc
Description: This is a digitally signed message part