mailing list archives
Re: CVE request: MediaWiki 1.22.5 login csrf
From: Florent Daigniere <florent.daigniere () trustmatta com>
Date: Sat, 29 Mar 2014 10:58:38 +0000
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
in... So the victim in this case would run the attacker's personal
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.
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.
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
Injection attacks (whether that's XSS, SQLi, ...) happen when there's a
misunderstanding (for one of the parties) in between what's data and
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
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
"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 ) .
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
-) the way the tokens are generated and compared is not okay (lazy
comparison in PHP, no constant time comparison, hash-length-extension
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
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 ;)
Description: This is a digitally signed message part