Issue J: Attacker May Be Able To Extract Secrets Through Side-Channel Attacks

[evilaliv3]

Synopsis: Information about various secrets leaks through the side channel of timing of operations.
Impact: The attacker can extract secrets by measuring the response time of the GlobaLeaks server.
Some candidate secrets include file download tokens, XSRF tokens, session IDs, and account names.

[vecna]

Fixes type 1 (authenticated ops)

J.4 (session ID guessing), J.5 (usernames), J.6 (receipt): those are function related authentication checks and authenticated users (also the WB): globaleaks/GLBackend@d6c9633da2e007c31c93431dc8597018afd81761
This commit define the function:

def uniform_answers_delay(self):
    """
    @return: nothing. just put a delay to normalize a minimum
       amount of time used by requests. this impair time execution analysis

    this safety measure, able to counteract some side channel attacks, is
    automatically disabled when the option -z and -l DEBUG are present
    (because mean that is run in development mode)
    """

    if GLSetting.loglevel == logging.DEBUG and GLSetting.devel_mode:
        return

    uniform_delay = 0.800
    request_time = self.request.request_time()
    needed_diff = uniform_delay - request_time

needed_diff is the amount of milliseconds waited before return an answer.

Fix type 2 (generic XSRF scope)

J.5 (XSRF cookie) is due a != usage, and not only in the authenticated operations, has been implemented using this function:

from cryptography.hazmat.primitives.constant_time import bytes_eq

This has been done in: globaleaks/GLBackend@f9a4b8951184561170c61a13f175c7ff7d68fe5b

not fixed

J.1 and J.2 has been removed by other patches

steve

@evilaliv3 @hellais please review

[vecna]

TODO update application security guidance

[evilaliv3]

i'm not totally convinced of fix 1: what happens if the attacker can control the response time (with large payloads for example) and making the system respond in more thant 800ms? in that case the side channel would be open again?

fix 2 is ok for me.

[evilaliv3]

@defuse: as written in the report this theorethical issue is demanded to future work. by the way we have implemented the remediation listed above. regarding my doubt we are going to open an improval ticket for future investigations.

can this ticket be considered addressed for the aim of the pentest remediation?

[defuse]

The fix for J.3 (number 2 above) looks really good. The fix for the others (number 1 above) is questionable, since it doesn't prevent side channel attacks based on caches or other things that unprivileged code on the same system might have access to. I think this ticket can be closed as long as another one is opened regarding that doubt (as you suggest).

[evilaliv3]

@fpietrosanti naif are you going to take care of this? (by tonight i will put all the old databases migration under unit test! stay tuned!)

[defuse]

Another concern I have is that it might not prevent an attacker from learning the timing differences. For example if request_time() was not very accurate or precise, then the end result might still have variations that depend on the secrets.

[fpietrosanti]

I've created ticket "Improve Side Channel Attack protection based on HTTP response throttling" at #865 for further improvements. It would be nice to have a generalized method/algorithm to do so.

[evilaliv3]

closing this ticket postponing the improvement to #865

[vecna]

@defuse @fpietrosanti @evilaliv3 I strongly believe is not realistic attack scenario after the patch.

The request_time checks "uniform" the answer time to 800 ms, enough time to check the memory variables (and also with a hundred of thousand keys in memory)

There are other three point to keep in account:

• A time path analysis scenario has "one nearly immediate answer" vs "one slow answer", not "two differently slow answer". Example: suppose to have 10ms answer when "this tried key exists" and 60ms answer as "this tried key do not exists [*]". going over the cap of the memory answer of a GL box under stress test (150-200 ms if there are not DB interaction), can simply cut off this analysis.
• The "entropy" in efficiency provided by the Tor channel (7 hop by default, 4 with a customized Tor client) would make every fine analysis gone.
• Using the 800ms boundaries, every answer appear in a range going since 810ms to 840ms, because there are other code involved beside just release the answer.

An improvement suggested in #865, in my knowledge, is wrong [**]. The idea suggested by the GL team, was "we can simply sum randin(0, 1000) ms for every answer. But do not solve the security issue, because you've just to bruteforce more. (the analysis here is quite simile the Passive Traffic Analysis based on packet size. PTA became crippled when covered with constant padding, not with random padding, and is the reason why interactive connection with strongly different size of packet have not random padding as coverage traffic: the resources expense its too high and the security obtained do not cover the expenses)

For these reason I don't get how a safe HTTP response throttling can be done, still preserving usability, and neither if its really needed, because the time path execution I've seen works in milliseconds of differences.

[*] also keeping in account that attacker can put a tons of valid keys creating a huge amount of Tip (impossible operation if anomaly detection is enabled)

[**] wrong because do not bring a stronger security effect but give an usability/efficiency drawback

p.s. comment updated after 5 minutes with details and fixes

[vecna]

Moved discussion in #865