Hacker News Reader

Comment by IgorPartola | Hacker News Reader

Is stuff like this vulnerability present in Django as well, and just not being discovered as quickly, or is there something in the water (or was there years ago) in the Rails camp that caused all these bugs?

View on HN

We don't know.

It's certainly possible. Maybe, maybe not.

The recent spate of Rails vulnerabilities - the really scary ones at least - all stemmed from the same root cause: folks were a little too lenient with how they handled YAML parsing.

Once that was discovered, a lot more attention has been directed to how Rails handles different kinds of parsing.

It's possible! that other frameworks have had similar cascading mistakes, but we won't know until more code reviews occur. Maybe in this particular case Rails-core was especially lenient, but (as far as I remember) dedicated security people have only taken a keener interest in the past year or so.

As others have said, Django may or may not have security issues. I wouldn't bet against it.

With regard to this vulnerability, however, the '^' and '$' regex pattern characters in python match the beginning and end (or end + '\n') of the string by default. Multiline mode has to be enabled explicitly:

import re

re.match(r'^test$', 'test\n multiline') == None

re.match(r'^test$', 'test\n multiline', re.MULTILINE) != None

So, I think it's a little less likely that this particular vulnerability would be an issue. It's still possible for someone to leave off the '$', but at least that case is a little more obvious.

Also, the Django codebase doesn't have any param processing code that uses whitelisting/blacklisting like this; you have to explicitly lookup values in request.GET and request.POST or use specific field names in a Form. It's a little less convenient compared to mass assignment, but more secure by default.

Django ModelForms[1] do seem (to my rails-ignorant self) to be quite similar to what's being described here.

    class SomeForm(ModelForm):
        class Meta:
            model = SomeModel
            fields = [ whitelist ]
            exclude = [ blacklist ]

Both fields and exclude are optional, if neither are specified 'all'[2] fields for the model will be included in the form.

[1] https://docs.djangoproject.com/en/1.4/topics/forms/modelform...

[2] The model can blacklist certain fields with editable=False in the field definition as well, which afaik trumps anything a ModelForm does.

For all the complaints in the Python community that Django contains too much magic, Rails is far more magical; and that magic add complexity that allows these kinds of problems to show up.

That is not to say Django doesn't have issues; it undoubtably does. I just think the hidden surface area is smaller.

Are there complaints in the Python community that Django contains too much magic? Serious question: I don't follow many Python/etc mailing lists so I'm pretty out of the loop on the general impressions people have of Django. I was kind of hoping that Django's magic-removal branch (merged all the way back in 2006!) would have helped here.

One of the core issues here was a serialization library that was too convenient, with the ability to deserialize into arbitrary classes and end up executing code from them. In the Python world, this vulnerability has been a bit better known for a while (which is not to say that they are immune, but it's at least been common community knowledge for a very long time now, at least a decade). Pickle is well-known to have it, but it's frequently pointed out in the docs that it is possible and that you shouldn't unpickle things from users. But other libraries may have this too, and if Django uses them, have a poke around. JSON libraries would be one obvious point. There's probably some extant Perl vulnerabilities in this area too. PHP wouldn't surprise me (though it would be a particular framework and probably not the language as a whole).

I doubt it's an issue of Python community vs Ruby community. Instantiating arbitrary objects is the sort of feature I'd expect an object serialization library to have, but not a document serialization library. Pickle is clearly an object serialization library, and I would have naively assume that YAML is a document serialization format, but apparently either the authors of the Ruby YAML parser or the creators of YAML don't see it that way, and see YAML as an object serialization format that is by default permitted to specify arbitrary objects to instantiate.

Python's YAML library is also capable of serializing python objects[1]. My understanding is the YAML spec allows these extensions but does not require them.

If you are using PyYaml.Loader instead of PyYaml.SafeLoader for anything coming from a user, you are at risk of this problem.

http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPython...

I'd be surprised if there wasn't at least one reasonably major PHP framework with similar sorts of vulnerabilities: while PHP's JSON decoder should be safe (it can't create any objects other than stdClass objects, which are simple property buckets), the use of unserialize() in older frameworks was rife (mostly due to a lack of alternatives), and that's definitely not safe with arbitrary user data -- as we've seen with the RoR issues, it only takes one code path where user data unexpectedly gets in somewhere it shouldn't.

AFAIK, the only way this could be an issue with the language is if you use serialize/unserialize, which can be used on classes. It goes without saying that this can be useful in certain contexts - such as file-based caching - but should not be relied upon too heavily.

I cannot remember the last time I came across a php project that did something similar.

CakePHP had an issue with unserialize() at one point. Since then we've wised up about using putting user data into unserialize()

Some popular Django third-party plugins had similar issues to the YAML problems back in 2011 (i.e. using YAML.load instead of safe_load). As noted in the sibling comment, the pickle module is well-known in the Python community for being susceptible to this as well.

Beyond that, your guess is as good as mine. I'm sure that /someone/ has been looking at Django at least to see if there are similar issues.

Don't know, but I do know we'll be investigating it.

(we tend to keep an eye out for issues affecting other frameworks/libraries, both to coordinate and to check our own stuff -- security is really damned hard, and the thing to do is watch and learn rather than point and laugh)

Reply on news.ycombinator.com