WAMP-CRA: potential timing attack

[oberstet]

The short version: it is very, very unlikely to be exploitable at all, but better be paranoid, so we do something.

I'll quote from IRC:

[01:03:18] <yury> hi
[01:03:56] <yury> there is a very small security leak in the wamp HMAC.
[01:04:48] <yury> while each ID is used for only one authentication attempt, a timing attack is possible to figure out (approximately) how much of the HMAC you guessed correctly.
[01:05:26] <yury> not very useful, but should a vulenaribility arise in HMAC, this could be a potential attack vector
[01:05:59] <yury> line 1899 in auth() in wamp.py
[01:06:33] <yury> I believe it would be better to not leak any information and take the extra time to compare byte by byte.
[06:00:17] <-- oberstet (~quassel@ppp-88-217-121-196.dynamic.mnet-online.de) hat das Netzwerk verlassen
[06:00:34] --> oberstet_ (~quassel@ppp-93-104-136-80.dynamic.mnet-online.de) hat #autobahn betreten
[06:00:34] *** Modus #autobahn +cnt by adams.freenode.net
[06:00:34] * Chat #autobahn wurde am 2012-03-06 01:02:27 UTC erzeugt
[06:00:34] [ChanServ] Autobahn WebSocket - Open-source client and server libraries for WebSocket and WAMP.
[06:00:34] * Webseite für #autobahn ist http://autobahn.ws
[06:04:15] <-- oberstet (~quassel@ppp-88-217-121-196.dynamic.mnet-online.de) hat das Netzwerk verlassen (Ping timeout: 260 seconds)
[06:22:28] --> normanm (~normanm@redhat/jboss/normanm) hat #autobahn betreten
[07:14:44] <oberstet_> yury: do I understand you right: the timing attack you mention would be based on the Python "!=" operator doing short-circuit evaluation on the string comparison .. that is return on the first octet being unequal .. and hence leak how many prefix octets are equal?
[07:16:42] <yury> yes
[07:16:50] <yury> exactly
[07:16:59] <yury> it is mostly averted by using each id only once
[07:17:04] <yury> but still leaks slightly
[07:19:30] <yury> if the same id was reused for all auth attempts, an attacker could easily figure out the hmac character by character. However, since the data to be hashed is changing, this is mostly a non-issue. Not sure if the fix (while trivial) is worth the performance hit (also trivial)
[07:20:13] <oberstet_> I see. It seems very unlikely to be exploitable .. this auth is over network, and timing variations introduced by network might trump the comparison op diffs. But I agree. Its there in principle. Thinking ...
[07:21:34] <oberstet_> we could do a) "slow", octet-wise comparison without short-circuit or b) compare as now, but raise/deny only after a random delay
[07:21:51] <yury> well, it is actually a very real and very exploitable attack, assuming the same data is being hashed
[07:22:22] <yury> both of those are in "common" use
[07:22:27] <oberstet_> but that isn't the case .. since the stuff hashed includes both a random value and a timestamp
[07:22:35] <yury> I believe bitmessage uses the random interval thing
[07:22:36] <oberstet_> each time
[07:22:38] <yury> agreed
[07:23:04] <yury> so it is mostly a non-issue, but a leak of information could come back and bite you in the butt later
[07:23:42] <oberstet_> I agree. better be paranoid. I do b). thanks for looking/caring!
[07:23:48] <yury> np
[07:24:01] <yury> glad the maintainer is security conscious
[07:24:23] <oberstet_> i am ... to level of peers calling me .. paranoid;)