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

evilaliv3 opened this Issue Apr 11, 2014 · 11 comments


None yet

4 participants


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.

@evilaliv3 evilaliv3 added this to the LeastAuthorityPentest milestone Apr 11, 2014
@evilaliv3 evilaliv3 self-assigned this Apr 11, 2014
@hellais hellais changed the title from Issue G. Confidential to Issue J. Confidential Apr 11, 2014
@vecna vecna assigned vecna and unassigned evilaliv3 Apr 12, 2014
vecna commented Apr 12, 2014

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-outdated@d6c9633
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:

    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-outdated@f9a4b89

not fixed

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


@evilaliv3 @hellais please review

vecna commented Apr 13, 2014

TODO update application security guidance


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 evilaliv3 changed the title from Issue J. Confidential to Issue J: Attacker May Be Able To Extract Secrets Through Side-Channel Attacks Apr 16, 2014

@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 commented Apr 16, 2014

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).


@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 commented Apr 16, 2014

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.


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.


closing this ticket postponing the improvement to #865

@evilaliv3 evilaliv3 closed this Apr 20, 2014
vecna commented Apr 21, 2014

@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 vecna reopened this Apr 21, 2014
vecna commented Apr 21, 2014

Moved discussion in #865

@vecna vecna closed this Apr 21, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment