5 ms·

I'm sure it will come, but I'd appreciate a layman's terms explanation of this. What is the threat, and how do you go about fixing things in Django?

steveklabnik 13y ago
Here's a simple explanation: http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ http://arstechnica.com/security/2013/08/gone-in-30-seconds-n... It's not Django, but us over at Rails have been discussing various parts of BREACH and how we'll handle it: https://github.com/rails/rails/pull/11729 https://github.com/rails/rails/pull/11729 The important two comments are here: https://github.com/rails/rails/pull/11729/#issuecomment-22066881 https://github.com/rails/rails/pull/11729/#issuecomment-2206... and https://github.com/rails/rails/pull/11729/#issuecomment-22083669 https://github.com/rails/rails/pull/11729/#issuecomment-2208... > Let's let this stew for a while with security researchers doing their > analysis on various approaches and wait and see what the security community > as a whole recommends. > > My only concern to rushing out a release is that we do something equally > dumb and end up creating a different problem for our users. > > We can roll out fixes as it becomes clear what the consensus is as to the > best solution for a generalised framework like Rails. As http://breachattack.com/ http://breachattack.com/ says: * Be served from a server that uses HTTP-level compression * Reflect user-input in HTTP response bodies * Reflect a secret (such as a CSRF token) in HTTP response bodies These things are easy to tell about your application, but are much harder for frameworks to detect generally, which is why projects like Django and Rails will take some time to evaluate exactly how to best handle this at the framework level.
skizm 13y ago
The link is like 5 sentences long and 2 of them are recommendations for stopping the attack.
- publicfig 13y ago
  Just because it's short doesn't mean it's simple to understand. Also, the recommendations aren't about how to fix things in Django, but instead a way to prevent this attack from happening. Hardly a long-term solution, especially because it basically asks you to avoid using GZIP for compression, which many people and organizations rely on in order to process timely responses.
Hovertruck 13y ago
This advisory is pretty understandable, I think. The big bold text ("BREACH may be used to compromise Django's CSRF protection") is a strong warning of the threat (becoming vulnerable to XSS). They list two steps that they recommend taking; disable the gzip middleware in your settings.py, and disable gzip for responses from your web server.
jeffasinger 13y ago
I'm not all that familiar with BREACH, so please correct me on the parts I'm wrong about, but it seems that it's an attack that allows one to recover some data sent over TLS if compression on TLS and the protocol level is enabled. In Django, this means that attackers could recover the CSRF token that's used to prevent cross site requests. This means anyone between you and a client could later have that client automatically make authenticated requests to your app, simply by visiting a site they control, without the knowledge of the user. To protect yourself, the Django team recommends turning off compression either at the TLS level and at the HTTP level.
- steveklabnik 13y ago
  The only part you're wrong about is the compression on TLS part, it's not an 'and': > While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying > gzip to allow for explicit separation of compression contexts in SPDY), > BREACH attacks HTTP responses. These are compressed using the common HTTP > compression, which is much more common than TLS-level compression. This > allows essentially the same attack demonstrated by Duong and Rizzo, but > without relying on TLS-level compression (as they anticipated). and > It is important to note that the attack is agnostic to the version of > TLS/SSL, and _does not require TLS-layer compression._ breachattack.com
IvyMike 13y ago
Imagine you're going to send a compressed and encrypted message to a friend, and I (the attacker) can do two things: 1) Append a bit to the message before it is compressed and encrypted. 2) See the size of the final message. So I start by appending the string "4179174b19e0cdc91bf4" to your plaintext message. I see the final encrypted message size is 500 bytes. Then, I redo the experiment, but this time, I append the string "cschmidt@example.com" to the message. The final encrypted message size is now 480 bytes. The string I injected was the same size, but the compression worked better this time, and I can guess it's because the string I picked is redundant with something in your plaintext. Mix in a bunch of complicated math and a bit of javascript, and you've got an exploit. This threat isn't specific to Django: it's being billed as a TLS attack, but any encryption system that uses compression the same way is vulnerable.
- deleted 13y ago
  [deleted]

steveklabnik 13y ago

Here's a simple explanation: http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ http://arstechnica.com/security/2013/08/gone-in-30-seconds-n... It's not Django, but us over at Rails have been discussing various parts of BREACH and how we'll handle it: https://github.com/rails/rails/pull/11729 https://github.com/rails/rails/pull/11729 The important two comments are here: https://github.com/rails/rails/pull/11729/#issuecomment-22066881 https://github.com/rails/rails/pull/11729/#issuecomment-2206... and https://github.com/rails/rails/pull/11729/#issuecomment-22083669 https://github.com/rails/rails/pull/11729/#issuecomment-2208... > Let's let this stew for a while with security researchers doing their > analysis on various approaches and wait and see what the security community > as a whole recommends. > > My only concern to rushing out a release is that we do something equally > dumb and end up creating a different problem for our users. > > We can roll out fixes as it becomes clear what the consensus is as to the > best solution for a generalised framework like Rails. As http://breachattack.com/ http://breachattack.com/ says: * Be served from a server that uses HTTP-level compression * Reflect user-input in HTTP response bodies * Reflect a secret (such as a CSRF token) in HTTP response bodies These things are easy to tell about your application, but are much harder for frameworks to detect generally, which is why projects like Django and Rails will take some time to evaluate exactly how to best handle this at the framework level.

skizm 13y ago

The link is like 5 sentences long and 2 of them are recommendations for stopping the attack.

publicfig 13y ago
Just because it's short doesn't mean it's simple to understand. Also, the recommendations aren't about how to fix things in Django, but instead a way to prevent this attack from happening. Hardly a long-term solution, especially because it basically asks you to avoid using GZIP for compression, which many people and organizations rely on in order to process timely responses.

Hovertruck 13y ago

This advisory is pretty understandable, I think. The big bold text ("BREACH may be used to compromise Django's CSRF protection") is a strong warning of the threat (becoming vulnerable to XSS). They list two steps that they recommend taking; disable the gzip middleware in your settings.py, and disable gzip for responses from your web server.

jeffasinger 13y ago

I'm not all that familiar with BREACH, so please correct me on the parts I'm wrong about, but it seems that it's an attack that allows one to recover some data sent over TLS if compression on TLS and the protocol level is enabled. In Django, this means that attackers could recover the CSRF token that's used to prevent cross site requests. This means anyone between you and a client could later have that client automatically make authenticated requests to your app, simply by visiting a site they control, without the knowledge of the user. To protect yourself, the Django team recommends turning off compression either at the TLS level and at the HTTP level.

steveklabnik 13y ago
The only part you're wrong about is the compression on TLS part, it's not an 'and': > While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying > gzip to allow for explicit separation of compression contexts in SPDY), > BREACH attacks HTTP responses. These are compressed using the common HTTP > compression, which is much more common than TLS-level compression. This > allows essentially the same attack demonstrated by Duong and Rizzo, but > without relying on TLS-level compression (as they anticipated). and > It is important to note that the attack is agnostic to the version of > TLS/SSL, and _does not require TLS-layer compression._ breachattack.com

IvyMike 13y ago

Imagine you're going to send a compressed and encrypted message to a friend, and I (the attacker) can do two things: 1) Append a bit to the message before it is compressed and encrypted. 2) See the size of the final message. So I start by appending the string "4179174b19e0cdc91bf4" to your plaintext message. I see the final encrypted message size is 500 bytes. Then, I redo the experiment, but this time, I append the string "cschmidt@example.com" to the message. The final encrypted message size is now 480 bytes. The string I injected was the same size, but the compression worked better this time, and I can guess it's because the string I picked is redundant with something in your plaintext. Mix in a bunch of complicated math and a bit of javascript, and you've got an exploit. This threat isn't specific to Django: it's being billed as a TLS attack, but any encryption system that uses compression the same way is vulnerable.

deleted 13y ago
[deleted]