Improve Side Channel Attack protection based on HTTP response throttling

[fpietrosanti]

This ticket is to improve Side Channel Attack protection based on HTTP response throttling based on the early implementation that has been done at #857 .

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[vecna]

check this comment: https://github.com/globaleaks/GlobaLeaks/issues/857#issuecomment-40921667

[evilaliv3]

@vecna i see only two issues in the solution implemented:

• it's not clear (from code point of view) where the solution the fix is currently used and where it has to be used in the future; problably we need to document it clearly somewhere.

• i've found various usability issues in the GLClient in various situation where the client click on something and a lot of delay happens showing an empty page. it happens for example:

  -- when a user click on a tip is showed empy for various time (more thant 1second) probably for dependant requests. -- when a user click on postpone, it happens the same and the new date for the postpone is showed after the 800ms of delay. this has showed me a coding bug of the glclient because the postpone configmration button was not disabled until full page load (i've fixed it in https://github.com/globaleaks/GLClient/commit/ba175e4a8040116a2b6725bc77167629874b55fa) -- others conditions surely exists.

[public]

You should try and actually measure some of these suspected side channels in controlled circumstances. It's often surprisingly easy to get them to show up and fixing something you can directly test gives you much more confidence that things are being fixed than stuff you are fairly sure exists but haven't actually seen :)

As people have noted, adding randomised, constant or other forms of time delay to requests is not a great solution. Throttling request rates is challenging to do well too as it's fairly easy for an attacker to use a widely distributed set of systems to carry out the requests required for analysing any timing side channel.

[fpietrosanti]

Let's say that for this feature, we need to write down a 1-2 page specification to acquire consensus on the proper way to do it?

Like #264 it seems that everything that involve timing always trigger a lot of debate, so it probably need to be specified in advance and peer-reviewed in order to acquire the needed consensus.

I'm confident that with proper timing management (random or constant, it's a matter of documenting the algorithm and it's drawback) an external/remote attacker would not be able to infere any kind of possibly present side-channel attack to be identified/exploited.

Think about the old OpenSSH bug http://www.cvedetails.com/cve/CVE-2003-0190/ that has been fixed just by adding a delay in order to defeat the timing analysis.

So, this make me to be convinced that this "approach" works, but probably we would need to:

• Specify it better
• Design an attack/measurement tool to verify it

/cc @defuse

[fpietrosanti]

Side Channel Vulnerabilities on the Web - Detection and Prevention https://www.owasp.org/images/c/cd/Side_Channel_Vulnerabilities.pdf

[fpietrosanti]

"Worst Case Execution Time" (WCET) is our friend

[fpietrosanti]

From what i read online looking at OWASP, IMHO the constant timing approach sounds like a good approach, we probably just need to:

• document it better
• apply it only to the "sensitive" part of the code (where a side channel can be exploited to gain some advantage) to mitigate the performance impact
• make a tool to measure/demonstrate that it effectively works

[public]

WCET makes DoS easier and is vulnerable to attacks to which increase the running time of the suspect algorithm beyond your anticipated WCET.

[fpietrosanti]

@public Well, any "delay based" system introduce possible additional attack surface from the DoS point of view, but it's always a matter on "what the worst scenario" you are protecting from.

But If we want to look towards following "best practices", the only paper to add layer of protection against side-channel attack on web application, is that one from owasp, that talk about WCET.

So, if we accept the additional risks of DoS because of added delay, the question is:

• Should we dynamically define/measure the WCET or set it statically?

Do you see any other possible defense-in-depth approach to this HTTP-side-channel issue?

[public]

In my opinion the correct solution is to identify which classes of data are sensitive in your application and to encapsulate them to prevent accidental leakage and provide side channel protected APIs for working with them. If you don't design the APIs that handle the sensitive data well then no amount of middleware is going to save you from inevitable coding errors.

This is also basically the the conclusion that this paper from Microsoft Research comes to. http://research.microsoft.com/pubs/119060/webappsidechannel-final.pdf

We also studied the challenges in mitigating such a problem, and show that effective and efficient mitigations have to be application-specific: developers will need to identify the vulnerabilities first, and then specify mitigation policies accordingly. This effort requires analysis of web application semantics, information flow and network traffic patterns. Public domain knowledge also needs to be examined in order to understand the real power of the attacker and the effectiveness of the defense.

[defuse]

Also consider side channels that are not based on the response time. For example, cache timing attacks, which can be performed by processes running as unprivileged users on the same system or on a different Virtual Machine that's running on the same hardware.

• http://eprint.iacr.org/2013/448.pdf
• http://cs.tau.ac.il/~tromer/papers/cache-joc-20090619.pdf
• http://eprint.iacr.org/2014/248 !!!

In my opinion, it is better to remove the side channel itself than to try to hide it.

[evilaliv3]

@vecna there are a lot of handlers that are not protected currently so that i think that it's better to introduce your patch only when fully implemented and audited. having some handler unprotected adds no protection and simply add usability issues.

list of handlers not protected:

• globaleaks/handlers/collection.py class CollectionDownload(BaseHandler) timing attacks are feasible on rtip_id
• globaleaks/handlers/files.py class Download timing attacks are feasible on rtip_id and file_id

in addition i think that this kind of uniform delay must evantually be applyed only to the secrets_check functions that in general are applied to the first part of the handler and takes ~5ms so that uniforming at 800ms is an exaggeration

[evilaliv3]

while we decide how to better refine the solution i've temporary removed it's application from the new release (2.60) except from the authentication handlers: https://github.com/globaleaks/GLBackend/commit/73cd9de5363254b21d2182199c9d95077a20870f

in fact:

• authentication secrets are the only one to be protected and without them no other side channel attack os feasible.
• if we do not close all the side channel attacks (as described in comment above), protecting only some of them leads only to usability issues.