In the meantime, workarounds include using 64 bit python, severely
limiting the length of requests your server accepts, limiting the
number of allowed parameters in a POST, and strictly limiting the
amount of time a Django process can exist before the webserver kills
it.
Fortunately, attack code has not yet been made public (if you know
otherwise please contact me privately).
Even though this issue is now public, please continue report security
problems privately to secu...@djangoproject.com.
-Paul
Even though this issue is now public, please continue report security
problems privately to secu...@djangoproject.com.
Thanks for the suggestion -- putting a link to the security mailing
contact on the community page definitely seems like a good idea to me.
I've just opened ticket #17479 to track this idea.
https://code.djangoproject.com/ticket/17479
For the record, the security contact is listed on the "create a new ticket page"
https://code.djangoproject.com/newticket
and in the FAQ:
However, it certainly doesn't hurt to have more links on our security
reporting procedures.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> So this would effect django because of the CSRF token check --- which requires the hash to be regenerated before comparing it yes?
No, the problem is somewhat different. The attacker constructs a POST request in which the field names are constructed to be a degenerate case of a hash table. Since pretty much every web framework in existence (including Django) automatically takes the incoming POST fields and inserts them into a hash table (a Python dict being implemented as a hash table), the framework will grind through this degenerate case very, very slowly.
If I'm reading the paper correctly, it only applies to 32-bit Python implementations, as the 64-bit ones are not practically vulnerable to this attack.
It's an interesting result, but I'm not sure how much to be worried about it in the field. A SlowLoris or similar attack would seem to be far more effective and less implementation-dependent.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Slow Loris can be avoided by putting a proxy capable of buffering
requests until completion between the app server and the web, right?
That seems like a simpler workaround than arch upgrade or replacing
dict implementation.
Yes, use nginx or similar. Slowloris is generally not a problem when
that is properly configured.
> That seems like a simpler workaround than arch upgrade or replacing
> dict implementation.
This problem has nothing to do with slowloris.
Replacing dict implementation prevents an attacker from producing keys
which are intentionally n^2 hard for dictionary operations.
Sure, I understand these are 2 different attack vectors. I just meant
that putting a proxy in front is a general solution that isn't
invasive to app code. It seems that this crafted-hash-collision
vector doesn't have a clean answer like that. There are workarounds,
but they may not apply to particular codebases.
Yeah. The discussion going on over at python-dev suggests that Python
itself may actually implement support after all, which would be really
nice.
--
It seems that Django has now become the argument for NOT fixing this
issue properly. Citing python-dev:
> For example, in the Django test
> suite, the HTML output is different at each run. Web browsers may
> render the web page differently, or crash, or ... I don't think that
> Django would like to sort attributes of each HTML tag, just because we
> wanted to fix a vulnerability.
We all know browsers won't crash and they will render the page exactly
the same. I volunteer to fix any issues in the test suite (considering
the hash changes also between 32-bit/64-bit Python, i'm not sure there
are even any or we would get a report on that, wouldn't we ?).
I think it's important for the Django core team to voice their opinion
on this matter in python-dev.
Thank you!,
Łukasz Rekucki
We all know browsers won't crash and they will render the page exactly
the same. I volunteer to fix any issues in the test suite (considering
the hash changes also between 32-bit/64-bit Python, i'm not sure there
are even any or we would get a report on that, wouldn't we ?).
I think it's important for the Django core team to voice their opinion
on this matter in python-dev.
I agree with this completely, and Carl's post:
http://mail.python.org/pipermail/python-dev/2012-January/115700.html
Whether this should be fixed in Python or not is a different question.
Most of the web specific problems can be fixed relatively easily with
HTTP specific solutions and limits. We can easily change how we handle
POST and GET data to a protected solution (by length limitation or a
custom datastructure), and we can protect cookie parsing using simple
length limits (and continue using stdlib SimpleCookie).
However, JSON parsing, which is a common task for web sites, is much
harder to fix, because almost by definition you've got to return
dictionaries with arbitrary keys and arbitrary size, and because as a
framework we don't control how developers do JSON parsing.
Luke
--
"Cross country skiing is great if you live in a small country."
(Steven Wright)
Luke Plant || http://lukeplant.me.uk/
I found these links very informative about this matter: http://lwn.net/Articles/474912/ and http://bugs.python.org/issue13703#msg150840 (the McMillan's post mentioned above).
- Anssi
________________________________________
From: django-d...@googlegroups.com [django-d...@googlegroups.com] On Behalf Of Luke Plant [L.Pla...@cantab.net]
Sent: Friday, January 20, 2012 15:46
To: django-d...@googlegroups.com
Subject: Re: DoS using POST via hash algorithm collision
On 20/01/12 08:47, Aymeric Augustin wrote:
> 2012/1/20 Łukasz Rekucki <lrek...@gmail.com <mailto:lrek...@gmail.com>>
>
> We all know browsers won't crash and they will render the page exactly
> the same. I volunteer to fix any issues in the test suite (considering
> the hash changes also between 32-bit/64-bit Python, i'm not sure there
> are even any or we would get a report on that, wouldn't we ?).
>
> I think it's important for the Django core team to voice their opinion
> on this matter in python-dev.
>
> Hello Łukasz,
>
> I absolutely agree -- code that relies on a deterministic dictionary
> order is broken and should be fixed.
I agree with this completely, and Carl's post:
http://mail.python.org/pipermail/python-dev/2012-January/115700.html
Whether this should be fixed in Python or not is a different question.
Most of the web specific problems can be fixed relatively easily with
HTTP specific solutions and limits. We can easily change how we handle
POST and GET data to a protected solution (by length limitation or a
custom datastructure), and we can protect cookie parsing using simple
length limits (and continue using stdlib SimpleCookie).
However, JSON parsing, which is a common task for web sites, is much
harder to fix, because almost by definition you've got to return
dictionaries with arbitrary keys and arbitrary size, and because as a
framework we don't control how developers do JSON parsing.
Luke
--
"Cross country skiing is great if you live in a small country."
(Steven Wright)
Luke Plant || http://lukeplant.me.uk/
--