Re: CVE request: MediaWiki 1.22.5 login csrf

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

On Sat, 2014-03-29 at 00:21 +0100, Jann Horn wrote:
> On Fri, Mar 28, 2014 at 06:13:49PM +0000, Florent Daigniere wrote:
> > > > > 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.
> > > >
> > > > It still doesn't make sense. Anti-CSRF tokens are only useful if the
> > > > "malicious script" is not running with the same origin!
> > >
> > > I think I threw you off here-- this is just one reason why an attacker
> > > might want to do this. It's tangential to the actual flaw we fixed.
> >
> > If mediawiki really allows users to define javascript that will be
> > loaded on pages they visit, that's a vulnerability... There's no way to
> > do that securely if the "content" and "application" data are served from
> > the same FQDN.
>
> MediaWiki allows users to define Javascript that will be loaded on pages they
> visit, *but only for themselves*. If I can inject JS into the pages I view,
> that is not a vuln, just like it isn't a vuln that a user can execute JS in
> the context of any website by pasting it into a debug console in his browser.

No, there's a fundamental difference in between one scenario and the
other; in one case the action is undertaken locally, in the other it's
not.

Injection attacks (whether that's XSS, SQLi, ...) happen when there's a
misunderstanding (for one of the parties) in between what's data and
what's meta-data.

Regarding XSS, in my books, if it's a browser-plugin (greasemonkey)
doing the injection, that's fine. If it's the user (your example) that's
fine too (but some people disagree : see
https://www.facebook.com/selfxss ).

If it's the server doing it, it's a vulnerability as there's just no way
of doing it "securely".

> However, this means that Login CSRF becomes a big security issue because it
> would allow me to add evil JS to my account and then force the browser of
> someone else to execute it in the context of the MediaWiki server's domain.

I had a look at how mediawiki generates its CSRF token... a smiley is
worth a thousand words. :XD

-> includes/User.php:getEditToken

"Anon" users (whatever that is) share a token (EDIT_TOKEN_SUFFIX).
Others have their pseudo-random "secret" hashed and stored in their
session... and it's spit out using "return md5( $token . $salt ) .
EDIT_TOKEN_SUFFIX;"

Few lines below is the function called matchEditToken(), *lazily*
evaluating the above against what it receives on the wire.

I won't bore you with the details, but the above is very unlikely to be
okay. In no particular order:
-) according to the above, "Anon" users share the same CSRF tokens
-) the attacker can force a session (and its secret) onto a user: ever
heard of http://www.php.net/manual/en/session.idpassing.php ? (grep
tells me that neither session.use_only_cookies nor session.use_trans_sid
are set)
-) the way the tokens are generated and compared is not okay (lazy
comparison in PHP, no constant time comparison, hash-length-extension
attacks, ...)

There's definitely a bunch of CVEs that could be assigned, but
fundamentally the security model of mediawiki can't work as long as that
"feature" exists.

I'll let someone else in the community pick it up from there. Ultimately
I'm not the one assigning CVEs... and probably won't be bothered enough
to put a PoC together. So I'll just GTFO ;)

Florent

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