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.
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:
@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.
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
J.1 and J.2 has been removed by other patches
@evilaliv3 @hellais please review
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.
@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?
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!)
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
@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:
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
Moved discussion in #865