Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebServer password check may expose timing attack #66

Closed
sweis opened this issue Dec 22, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@sweis
Copy link

commented Dec 22, 2017

This password check in the WebServer will return on the first character that mPassword and inPassword differ on. This may expose a timing attack where someone can recover the password through repeated queries:
https://github.com/guardianproject/haven/blob/master/src/main/java/org/havenapp/main/service/WebServer.java#L56

@b-meson

This comment has been minimized.

Copy link

commented Dec 22, 2017

ohhhh good find @sweis ! I think you're right

@noncombatant

This comment has been minimized.

Copy link

commented Dec 23, 2017

Note that the same problem is present a few lines down:

(!mSession.equals(inSid)))

Also it's worth investigating whether or not java.util.UUID.randomUUID is cryptographically random on your platform (Android in this case).

@conorsch

This comment has been minimized.

Copy link

commented Dec 23, 2017

@sweis Thanks for reporting this, great find. The timing attack you identify definitely warrants a patch.

Beyond fixing the basic authentication prompt, there's more we can do to frustrate an attacker's attempts to view the event log remotely. In @micahflee's OnionShare, for example, the Onion URL by appending random words to domain, e.g. .onion/word1-word2. So an attacker would already need to know not only the Onion URL, but the randomly generated route within that domain.

Better yet, Orbot recently added support for Authenticated Onion Services, which are Onion URLs that cannot be resolved unless the Tor client provides an auth cookie. (See the Tor manual, and search for "HidServAuth".) Setting them up requires a bit more overhead for the user, but the extra work provides additional security guarantees that are hard to beat. I'll open a separate issue to discuss implementing authenticated onion services in Haven.

@conorsch

This comment has been minimized.

Copy link

commented Dec 23, 2017

I'll open a separate issue to discuss implementing authenticated onion services in Haven.

No need—@mrphs already did so, in #41. 🤘

@thomorl

This comment has been minimized.

Copy link

commented Dec 23, 2017

@noncombatant I will check the Android implementation of java.util.UUID.randomUUID, but even if the standard implementation might be safe, different (and maybe wrong) implementations are still able to expose vulnerabilities, so it should be considered to add a check here.

@thomorl

This comment has been minimized.

Copy link

commented Dec 24, 2017

OK, as far as I can judge, UUID.randomUUID implementation is safe.
(Source file)

The random UUID is generated by a SecureRandom generator, which is created according to the Android guidelines:

// [Line 95]
private static class Holder {
    static final SecureRandom numberGenerator = new SecureRandom();
}

The function generating the UUID seems secure to me, too:

public static UUID randomUUID() {
    SecureRandom ng = Holder.numberGenerator;

    byte[] randomBytes = new byte[16];
    ng.nextBytes(randomBytes);
    randomBytes[6]  &= 0x0f;  /* clear version        */
    randomBytes[6]  |= 0x40;  /* set to version 4     */
    randomBytes[8]  &= 0x3f;  /* clear variant        */
    randomBytes[8]  |= 0x80;  /* set to IETF variant  */
    return new UUID(randomBytes);
}

Although the specification states that

A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1,

different implementations of the SecureRandom class might not follow this guidelines and therefore could break the security of the randomly generated UUID's; but the implementation itself is secure.

@n8fr8

This comment has been minimized.

Copy link
Member

commented Dec 27, 2017

Any comments on the fix supplied in #88 ? The safeEquals() method seems like it addresses the main points raised here.

@b-meson

This comment has been minimized.

Copy link

commented Dec 27, 2017

@n8fr8 I think that PR looks good.

@n8fr8 n8fr8 closed this in #88 Dec 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.