Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



WebApp Sec: Re: XML DTD entity blowup

Re: XML DTD entity blowup

From: Kurt Seifried <bt_at_seifried.org>
Date: Thu, 16 Oct 2003 22:19:19 -0600

>Would you happen to have more information about the following type of
error?
>
>XML DTD entity blowup - Multiple vendors XML parser (and
>SOAP/Web services server) denial of service attack
>
>If someone knows how to fix it, I will appreciate any information.
>
>Best regards,
>Manuel

I assume you are referring to user specified DTD files and the like (from
Dec 16, 2002, my how time flies).

In theory you could make a parser that tries to figure out if the XML is
"hostile" or not (i.e. does it do some function in a loop a million times,
thus starving resources?) but due to complexity (and the classic "Turing
halt problem") it's essentially impossible to build a parser that would
catch all "hostile" XML.

It's basically the same problem for Macro's/email/HTML/etc, so many parsers
(IE/Mozilla/Opera, Outlook/Eudora/etc) with different "interpretations" and
capabilities, figuring out what is potentially hostile, or heck figuring out
how it iwll be prased is nigh impossible.

I think it's like any processing of (potentialy hostile) user data that is
also executable (i.e. scripting, or can call other entities), simply place
resource limits on each instance, when they use up their 5 megs of ram and
10 seconds of CPU time kill them. This still allows for denial of service
attacks but at least minimizes them to a degree. Also place limits on who
you accept data from, and if you must accept XML data from untrusted sources
I'd suggest having two servers, one for critical trusted data and one for
untrusted data if possible. If you can prevent a user from specifying
external entities that helps a bit to, but won't completely solve the
problem.

Kurt Seifried, kurt_at_seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/
Received on Oct 17 2003

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]