[Python-Dev] XML DoS vulnerabilities and exploits in Python

Steven D'Aprano steve at pearwood.info
Thu Feb 21 01:37:47 CET 2013

On 21/02/13 10:22, Antoine Pitrou wrote:
> On Wed, 20 Feb 2013 18:21:22 -0500
> Donald Stufft<donald.stufft at gmail.com>  wrote:
>> On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote:
>>>> It's not a distributed DoS issue, it's a severe DoS vulnerabilities. A
>>>> single 1 kB XML document can kill virtually any machine, even servers
>>>> with more than hundred GB RAM.
>>> Assuming an attacker can inject arbitrary XML. Not every XML document
>>> is loaded from the Internet.
>> Even documents not loaded from the internet can be at risk. Often times
>> security breaches are the result of a chain of actions. You can say "I'm
>> not loading this XML from the internet, so therefore I am safe" but then
>> you have another flaw (for example) where you unpack a zip file
>> without verifying there are not absolute paths and suddenly your xml file has
>> been replaces with a malicious one.
> Assuming your ZIP file is coming from the untrusted Internet, indeed.
> Again, this is the same assumption that you are grabbing some important
> data from someone you can't trust.

It's easy to forget that malware existed long before the Internet. The internet is just a transmission vector, it is not the source of malicious files. The source of malicious files is *other people*, and unless you never use XML files you didn't generate yourself, you cannot completely trust the source. You might trust your colleagues to not *intentionally* pass you a malicious XML file, but they may still do so accidentally.

The risk seems small, these days, but remember that for decades the sole transmission vector for viruses and other malware was *people you trusted* not to deliberately give you a virus.

> Just because you are living in a Web-centric world doesn't mean
> everyone does. There are a lot of use cases which are not impacted by
> your security rules. Bugfix releases shouldn't break those use cases,
> which means the security features should be mostly opt-in for 2.7 and
> 3.3.

I think that is reasonable. Insecure by default or not, code should not suddenly stop working because I've upgraded from 2.7.3 to 2.7.4.


More information about the Python-Dev mailing list