On Sat, 2012-01-21 at 23:47 +0000, Alex Gaynor wrote:
> Alex Gaynor <alex.gaynor@gmail.com> added the comment:
> 
> On Sat, Jan 21, 2012 at 5:42 PM, Gregory P. Smith <report@bugs.python.org>wrote:
> 
> >
> > Gregory P. Smith <greg@krypto.org> added the comment:
> >
> > On Sat, Jan 21, 2012 at 2:45 PM, Antoine Pitrou <report@bugs.python.org>
> > wrote:
> > >
> > > Antoine Pitrou <pitrou@free.fr> added the comment:
> > >
> > >> You said above that it should be hardcoded; if so, how can it be changed
> > >> at run-time from an environment variable?  Or am I misunderstanding.
> > >
> > > You're right, I used the wrong word. I meant it should be a constant
> > > independently of the dict size. But, indeed, not hard-coded in the
> > > source.
> > >
> > >> > > BTW, presumably if we do it, we should do it for sets as well?
> > >> >
> > >> > Yeah, and use the same env var / sys function.
> > >>
> > >> Despite the "DICT" in the title?  OK.
> > >
> > > Well, dict is the most likely target for these attacks.
> > >
> >
> > While true I wouldn't make that claim as there will be applications
> > using a set in a vulnerable manner. I'd prefer to see any such
> > environment variable name used to configure this behavior not mention
> > DICT or SET but just say HASHTABLE.  That is a much better bikeshed
> > color. ;)
> >
> > I'm still in the hash seed randomization camp but I'm finding it
> > interesting all of the creative ways others are trying to "solve" this
> > problem in a way that could be enabled by default in stable versions
> > regardless. :)
> >
> > -gps
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report@bugs.python.org>
> > <http://bugs.python.org/issue13703>
> > _______________________________________
> >
> 
> I'm a little slow, so bear with me, but David, does this counting scheme in
> any way address the issue of:
> 
> I'm able to put N pieces of data into the database on successive requests,
> but then *rendering* that data puts it in a dictionary, which renders that
> page unviewable by anyone.

It doesn't address this issue - though if the page is taking many hours
to render, is that in practice less unviewable that everyone getting an
immediate exception with (perhaps) a useful error message?

Unfortunately, given the current scale factor, my patch may make it
worse: in my tests, this approach rejected malicious data much more
quickly than the old collision-counting one, which I thought was a good
thing - but then I realized that this means that an attacker adopting
the strategy you describe would have to do less work to trigger the
exception than to trigger the slowdown.  So I'm not convinced my
approach flies, and I'm leaning towards working on the hash
randomization patch rather than pursuing this.

I need sleep though, so I'm not sure the above is coherent
Dave