Hacker News Reader

(Disclaimer: I'm the other guy behind BundleScout.)

The Django project does a fantastic job with announcements. (So does Rails.) And if every open source project had the infrastructure to make that much noise, the world would be a better place. But of the 100k or so Python/Ruby/NPM projects I know about, only a small handful do, or could even manage it.

And if they did, would you want to be on every one of their mailing lists?

Bleach, for example, has more users than I have twitter followers, so I doubt most of them heard about v1.2.1. (Out today! Go get it!)

> but it kinda sucks that you'd make people pay to hear about security issues

Well, like you said, there are other ways to hear about updates, at least from the big projects. This is the convenience of not needing to join dozens of mailing lists and/or check dozens of websites periodically.

Would you maybe consider making a distinction between security releases and regular run-of-the-mill update releases?

I see a real value in a service to let me know that there's a new version of one of the dozens of things I depend on. But like I said, it seems janky to rely on a for-pay service to find out about security vulnerabilities. So what about making the security notification free to all users, with the non-security update notifications a for-pay addon? Seems like a good way to strike a balance between developing a self-sustaining business and helping out a community.

Consider it? Definitely. But semver doesn't make a distinction, either, so it's a hard problem.

If you don't mind, we'd love to get your thoughts more via email--don't want to hijack this thread too much.

I appreciate this.

Second, I think the severity of XML external entity injection is understated in the advisory. This class of vulnerability isn't just a DoS in general. Does something about Django specifically limit the impact to just a DoS?

Yes: Django only uses XML in one very limited place, the serialization parsing framework, which isn't exposed publicly in any way. It's used for data backup/restore as well as for test fixtures, but that's it. Further, the same framework also supports JSON, and it's extremely rare to find a Python developer who's going to chose XML over JSON. So in terms of Django itself the attack surface is extremely small.

That said, if you're parsing XML in your own code you should be looking at defusedxml, also announced today: http://blog.python.org/2013/02/announcing-defusedxml-fixes-f.... So maybe we should make a bigger point about that? If you've got suggested edits to the announcement let me know, happy to incorporate 'em.

What about it makes it under stated? What besides a DoS do you see being made available because of entity expansion?

The vulnerability we fixed is not just entity expansion, it's also accessing external entities. Although this is a DoS vector, I think it's true that it could be used to gain information about the presence or absence of files on the local filesystem, or even potentially information about their contents (given access to the results of XML parsing).

You can also use it to reference arbitrary remote URIs. Suddenly your XML parser is making outbound connections to anywhere the attacker specifies, looking for more XML to process.

On some Windows systems, you can use a UNC path (\\share) and force the parser to try and connect to a share that the attacker controls, which will cause windows to hand over the user's hash during the handshake.

The impact varies with the platform and parser being used, and with the extensions installed. I don't know the specifics of ExpatParser (the one used by Django), but in general, the "careless" parsing of unsanitized user-supplied XML might lead to:

- DoS

- Disclosing of sensitive files (in general, the XML has to "validate". In PHP, it's always possible to read any file accessible by the process parsing the XML).

- Making arbitrary network connections (with this an attacker can portscan a network, attack vulnerable services that would be protected by firewall, and/or use the vulnerable server as a restricted kind of proxy).

- Probing LDAP directories.

- Remote code execution.

See, for instance:

http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_...

http://defcon.org.ua/data/2/2_Vorontsov_XXE.pdf

http://www.insinuator.net/2013/01/rails-yaml/

Edit: As a clarification, I'm not implying that any of the above (apart from the DoS issue) is applicable to Django. I'm just saying what can possibly happen (and often happens for PHP apps).

You're right, thanks for pointing this out. Although (as jacobian mentions) Django's exposure in general to these attacks was quite limited, we still shouldn't describe these XML vulnerabilities as DoS-only.

I'm working on updates to the release announcement and release notes for 1.3.6 and 1.4.4 to make this clearer.

The advisory and release notes are now fixed to not describe the XML vulnerabilities as DoS.

After the recent Rails issue we added a PagerDuty service which is subscribed to django-announcements. When it gets a message from the list it filters the subject for "security" and alerts the on-call engineer who can evaluate the severity (as it applies to us).