Last modified: 2014-03-03 19:20:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T63346, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 61346 - Timing attack on Token
Timing attack on Token
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-13 23:01 UTC by Chris Steipp
Modified: 2014-03-03 19:20 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Check xor of tokens (1.43 KB, patch)
2014-02-14 01:26 UTC, Chris Steipp
Details
Check xor of tokens (1.98 KB, patch)
2014-02-20 00:00 UTC, Chris Steipp
Details

Description Chris Steipp 2014-02-13 23:01:26 UTC
Aaron pointed out that when checking the Token cookie, we use a string comparison, which could allow someone to brute-force the correct token faster than brute-forcing the entire key space.

$passwordCorrect = ( strlen( $token ) && $token === $request->getCookie( 'Token' ) );


This should use a constant time comparison (xor and check if the result > 1)
Comment 1 Chris Steipp 2014-02-14 01:26:46 UTC
Created attachment 14585 [details]
Check xor of tokens
Comment 2 Aaron Schulz 2014-02-18 23:22:48 UTC
Looks fine, but that comparison should go in it's own protected method.
Comment 3 Chris Steipp 2014-02-20 00:00:00 UTC
Created attachment 14631 [details]
Check xor of tokens
Comment 4 Aaron Schulz 2014-02-20 21:05:42 UTC
Looks mergable
Comment 5 Chris Steipp 2014-02-21 01:23:36 UTC
Deployed today, and we'll add it to the next release in a couple of weeks.
Comment 6 Bawolff (Brian Wolff) 2014-02-28 02:57:25 UTC
For reference, see I2a9e89120f7092015495e638c6fa9f67adc9b84f (Looks like gerrit bot can't edit security bugs)
Comment 7 T. Gries 2014-02-28 11:20:24 UTC
I guess there are more routines and many more _Extensions_ which should start using the constant-time compareSecrets function.
Comment 8 T. Gries 2014-02-28 11:20:58 UTC
Chris, next time pls. inform me directly.
Comment 9 T. Gries 2014-02-28 11:28:42 UTC
Not sure, if the following lines in your patch are correct as they make the function return quickly if the lenghts are unequal -> timing attack made easy

		if ( strlen( $answer ) !== strlen( $test ) ) {
+			$passwordCorrect = false;
+		} else {
Comment 10 Chris Steipp 2014-03-01 00:10:53 UTC
(In reply to T. Gries from comment #9)
> Not sure, if the following lines in your patch are correct as they make the
> function return quickly if the lenghts are unequal -> timing attack made easy
> 
> 		if ( strlen( $answer ) !== strlen( $test ) ) {
> +			$passwordCorrect = false;
> +		} else {

We could move this check out of the function, so the function is always constant time. But in this context, MediaWiki user tokens have been 32 characters since 2004, so knowing that the token is 32 characters doesn't give an attacker any extra information.
Comment 11 Chris Steipp 2014-03-03 19:10:59 UTC
This was assigned CVE-2014-2243. http://www.openwall.com/lists/oss-security/2014/03/01/2

I'm closing this bug since the token comparison in MediaWiki core is fixed. For this vulnerability in other extensions, let's open a separate bug for each, so we can track those separately.
Comment 12 T. Gries 2014-03-03 19:20:40 UTC
> let's open a separate bug for each, so we can track those separately.
Yes! Thx. Don't forget to mail me directly in case you detect further issues.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links