Anssi
From: django-developers@googlegroups.com [django-developers@googlegroups.com]
On Behalf Of Luke Plant [l.plant...@cantab.net]
Sent: Friday, January 20, 2012 15:46
To: django-developers@googlegroups.com
Subject: Re: DoS using POST via hash algorithm collision
On 20/01/
On 20/01/12 08:47, Aymeric Augustin wrote:
> 2012/1/20 Łukasz Rekucki mailto:lreku...@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/6
2012/1/20 Ł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, woul
Dear django-developers,
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 t
Hi Luciano,
Curious, I was unaware of any such DoS vulnerability - makes for very
interesting reading.
Thanks for sharing this with the list - may be worth sending to
django-users as well.
Cal
On Thu, Dec 29, 2011 at 2:26 AM, Luciano Pacheco wrote:
> Hi all,
>
> Have you guys seen this?
> htt
> 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 a
On Thu, Dec 29, 2011 at 12:10 PM, Paul McMillan wrote:
...
>> 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 intent
> Slow Loris can be avoided by putting a proxy capable of buffering
> requests until completion between the app server and the web, right?
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
On Thu, Dec 29, 2011 at 8:19 AM, Christophe Pettus wrote:
...
> 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.
Slow Loris can be avoided by putti
Thanks
On Thu, Dec 29, 2011 at 11:36 AM, Alex Gaynor wrote:
>
>
> On Thu, Dec 29, 2011 at 10:32 AM, Daniel Sokolowski <
> daniel.sokolow...@klinsight.com> wrote:
>
>> Would someone be so kind and explain why POST variables are stored in
>> hash tables? What is the reasoning behind it? Speed? Or
On Thu, Dec 29, 2011 at 10:32 AM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:
> Would someone be so kind and explain why POST variables are stored in hash
> tables? What is the reasoning behind it? Speed? Or is this simply done at
> the Python level when using a dictionary type? Th
Would someone be so kind and explain why POST variables are stored in hash
tables? What is the reasoning behind it? Speed? Or is this simply done at
the Python level when using a dictionary type? Thank you
On Thu, Dec 29, 2011 at 11:19 AM, Christophe Pettus wrote:
>
> On Dec 29, 2011, at 8:12 AM,
On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote:
> 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 a
So this would effect django because of the CSRF token check --- which
requires the hash to be regenerated before comparing it yes?
On Wed, Dec 28, 2011 at 9:26 PM, Luciano Pacheco wrote:
> Hi all,
>
> Have you guys seen this?
> http://www.ocert.org/advisories/ocert-2011-003.html
>
> PDF with som
On Thu, Dec 29, 2011 at 11:48 AM, Luciano Pacheco wrote:
>
>
> On Thu, Dec 29, 2011 at 1:56 PM, Paul McMillan wrote:
>>
>>
>> Even though this issue is now public, please continue report security
>> problems privately to secur...@djangoproject.com.
>
>
>
> Hi Paul,
>
> Thanks for your response.
>
On Thu, Dec 29, 2011 at 1:56 PM, Paul McMillan wrote:
>
> Even though this issue is now public, please continue report security
> problems privately to secur...@djangoproject.com.
Hi Paul,
Thanks for your response.
I've searched our community page for this address, before send to djang-dev
l
Yes, we've seen it and are working on it. Python hasn't directly
addressed the problem (and may not - it's arguable whether it's an
application or a language-level issue), so we'll probably have to ship
our own workaround. This is a non-trivial fix.
In the meantime, workarounds include using 64 bi
Hi all,
Have you guys seen this?
http://www.ocert.org/advisories/ocert-2011-003.html
PDF with some more explanation:
http://www.nruns.com/_downloads/advisory28122011.pdf
Regards,
--
Luciano Pacheco
blog.lucmult.com.br
--
You received this message because you are subscribed to the Google Group
18 matches
Mail list logo
