Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Issue J: Attacker May Be Able To Extract Secrets Through Side-Channel Attacks #857
Synopsis: Information about various secrets leaks through the side channel of timing of operations.
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
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:
This has been done in: globaleaks/GLBackend-outdated@f9a4b89
J.1 and J.2 has been removed by other patches
@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).
referenced this issue
Apr 17, 2014
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