On Aug 29, 9:43 pm, dave b <db.pub.m...@gmail.com> wrote:
> > OK, so you don't believe the advice you are getting, which is that of
> > the many issues a Django sit will face this is a relatively low
> > probability attack. That's fair enough - a vulnerability is a
> > vulnerability, after all, no matter how improbable, and not everyone
> > will set up their production systems to be correctly protected by a
> > front-end server.
>
> > If you really want to see this in Django you would be better advised to
> > post it in the issue tracker, where it will not get lost.
>
> Ok I will do this :-)
>
> Sure Also, Wow gmail is a horrible email client. I am so used to $else.
> The patch I included in my previous email should not break any *real*
> clients, only evil ones(potentially).
>
> As I understand it an attacker can abuse gzip user requests, if
> mod_deflate is enabled (AND configured to decompress incoming user
> requests - this is not the default) in apache2 with a user gziped
> request body.
You are again possibly getting overly worried about nothing here.
This is because use of a mutating input filter such as mod_deflate
with a WSGI based application is not possible.
As I said before, a WSGI application is not supposed to read more
content than is specified by the request content length, if it is, it
is a non compliant WSGI application.
For the case of mod_deflate, in decompressing the request content, it
cannot know in advance what the new content length will be. As such,
it leaves the original content length header intact. This means that a
conforming WSGI application would still only read up to that original
content length even if you were to enable mod_deflate. The result
being that the decompressed request content would actually be
truncated at the content length specified for the original compressed
content.
In short, you can not use mod_deflate on request content with
conforming WSGI applications as that would only read up to the
original content length. I have blogged about this limitation of WSGI
in the past, so maybe you should go search through postings on my
blog.
As I asked you before, have you actually run tests to prove your
hypothesis that this is all broken? If you have, then post what
hosting configuration and software you are using.
Graham
> So an attack could do effectively have a file like this:
>
> f = open("rar", "w")
> string = ""
> for i in range(0, 10000000):
> string += " " + "1"
> f.write(string)
> f.close()
>
> ls -lah 20M 2010-08-29 17:15 rar
>
> (except replace write with append and do it a lot more ;) ) and then
> send it gziped as in the request body.
>
> Just for fun ;)
> gzip rar
> ls -lah 19K 2010-08-29 17:15 rar.gz
>
> So django will receive the original 20M file (as the httpd has
> uncompressed it for django ) afaik.
>
> see Input Decompression
> athttp://httpd.apache.org/docs/2.0/mod/mod_deflate.html
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
