Hacker News Reader

Comment by lawnchair_larry | Hacker News Reader

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?

View on HN

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.

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.

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).

Reply on news.ycombinator.com