Critical Django security updates released (0day, exploit in the wild) | Hacker News Reader

Critical Django security updates released (0day, exploit in the wild)

djangoproject.com

73 pointsubernostrum10 comments

Less than four hours between the disclosure and the fix. Not bad.

Here's the changeset that fixes it: http://code.djangoproject.com/changeset/11603

Could someone as an intellectual exercise explain how this exploit works? I understand the idea of how some strings can throw a regex FSM off its game, but I can't see how it would happen here.

A simple rule of thumb is: nested repetitions may take 'forever' to fail.

If you've got Java applet support in your browser, here's an animated example...

http://regex.powertoy.org/?pat=m/((a{0,5}){0,5})*[e]/g&a...

...based on the "WARNING: Particularly complicated..." example in the Perlre docs:

http://perldoc.perl.org/perlre.html

You can see that Django's problematic domain-validation regexes were similar to the perlre example, but even worse -- a one-or-more of unbounded length, inside a 0-or-more of unbounded length, inside a 1-or-more of unbounded length:

http://code.djangoproject.com/changeset/11603#file0

This reminds me of a presentation on regular expression DoS attacks:

http://www.checkmarx.com/Upload/Documents/PDF/Checkmarx_OWAS... [pdf]

Quick view: https://docs.google.com/gview?url=http%3A%2F%2Fwww.checkmarx...

P. S. Corrected wording.

As mentioned above, this issue was initially disclosed publicly on a high-traffic mailing list. We'd like to remind our users that the correct channel for security reports is to send them to security@djangoproject.com. This allows the development team time to develop a solution and coordinate disclosure, both to the Django community as a whole and to the numerous third parties who maintain and distribute packaged versions of Django.

When debating whether a particular issue impacts security, we ask that you err on the side of caution and always contact security@djangoproject.com; we will be more than happy to work with you in analyzing and assessing potential security issues.

That way, the people that missed the issue in the first place are the only ones that will have the opportunity to fix it. While you wait, the crackers have already compromised your site.

Public disclosure without giving a vendor or project a chance to fix the issue before you release the information publicly screws everyone running it who may or may not have the skills needed to fix the issue.

In this case, it was a mistake. Luckily, it's only a DOS - there's worse things that could happen.

Only a DOS is bad for those high profile sites that are listed on your 'look who is using product X' pages.

Everybody else will probably squeak by without harm.

So...svn update?

Obviously if you're running off of any SVN other than the 1.1 tag, yes.

Reply on news.ycombinator.com