[jdev] Security-related thought experiment

Mon Mar 27 08:59:53 CST 2006

*bump*

I personally think this is a rather serious issue, perhaps warranting  
a "Best-practices" JEP for server developers. As XMPP becomes more  
and more popular, it is only a matter of time before script-kiddies  
start causing trouble.

What I'm thinking is a JEP which describes the attack and ways to  
prevent it from being successful. Then it makes it easy for server  
authors to communicate if their server is hardened against this type  
of attack: "AcmeJabD 0.3 is JEP-01xx compliant"...

Any thoughts? Good idea? Better solution? Am I making this out to be  
bigger than it actually is?

On Mar 24, 2006, at 10:32 PM, Robert B Quattlebaum, Jr. wrote:

> I was thinking the other day about a specific type of denial-of- 
> service attack which may possibly affect a number of servers in  
> active use today.
>
> Imagine a c2s connection that has already been set up and is now  
> moving top-level stanzas. What would happen if I sent
>
> <message to="randomjid at jabber.org"><body>
>
> Followed by a stream of random UTF-8 characters? Assuming that  
> those random characters do not happen to contain <, >, or &, (which  
> is pretty easy to ensure), I would imagine that the process which  
> has the XML parser would get larger and larger until the process  
> would run out of memory. Boom.
>
> This attack (in spirit) doesn't require a fully established jabber  
> stream, it only needs an opportunity to inject a large amount of  
> data into an XML element that is inside of a top-level stanza. This  
> attack could possibly work for attributes as well.
>
> Limiting the size of a single stanza may or may not fix the  
> problem, depending on implementation. If the stanza size filter is  
> applied to the stanza after it has been parsed, then this isn't  
> good enough--the attack will still be successful because the stanza  
> will never finish parsing. However, if the parser kept track of how  
> large the stanza was getting as it was parsing it, then this attack  
> can be avoided.
>
> Any thoughts, or other methods of preventing this attack from being  
> successful? Or has this already been considered and "fixed"?

__________________
Robert Quattlebaum
Mobile: +1(650) 223-4974
eMail:  darco at deepdarc.com
Jabber: darco at deepdarc.com
WWW:    http://www.deepdarc.com/