[<prev] [next>] [day] [month] [year] [list]
Message-ID: <5315E723.9060904@redhat.com>
Date: Tue, 04 Mar 2014 15:45:55 +0100
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: XML entity processing hardening
I'm in contact with an upstream for an XML processing library who do not
want to disable entity processing for the embedded DTD subset.
What are recommended practices if you have to do full entity processing,
but still want to avoid DoS (CPU and memory issues)?
Here's what I came up with:
CPU and memory are separate concerns because depending on the
implementation, empty entity references may not result in memory
consumption, but they may still need impossible large amounts of CPU
time to process. However, I think it is possible to address the CPU
aspect purely with memory accounting if we pretend that every entity
reference expands to at least one character, even if it is empty.
Apart from that, I think it is sufficient to approximate the character
count in fully-expanded serialized XML content. This "memory cost"
would have to memoized for each entity, and counted during entity
expansion itself and eventual document generation. During parsing, the
cost encountered is compared against a pre-computed limit.
The upper cost limit I suggest is 10 times the document size (perhaps
including the content of external entities, if enabled and parsed, not
entirely sure about that), plus a fixed baseline of (say) 1 MiB. These
numbers are obviously totally arbitrary, but hopefully, they grant
sufficient flexibility.
--
Florian Weimer / Red Hat Product Security Team
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
