Fwd: Instant disconnect vulnerability

Mark Doliner mark at kingant.net
Sun Aug 15 03:27:58 EDT 2010

On Fri, Aug 13, 2010 at 1:08 PM, Paul Aurich <paul at darkrain42.org> wrote:
> On 2010-08-13 10:17, Mark Doliner wrote:
>> ---------- Forwarded message ---------- From: Cory McIntire
>> <cory at cpanel.net>
> <snip/>
>> I'm not sure this is even really a vulnerability or just a DoS type
>> thing, but its working on multiple platforms.
>> I am using Adium 1.3.10 on a Mac OS X 10.6.4, but we've reproduced
>> this on Pidgin 2.7.2, libpurple 2.7.2 on an Arch Linux workstation.
>> AMD Athlon 64 X2 Dual Core Processor 6400+ 2.6.34-ARCH SMP.
>> The easiest way to reproduce is with this command on Mac:
>> debaser:~ cory$ echo -ne '\013' | pbcopy
>> Then simply paste that into an IM or Conference Jabber chat.. it
>> seems limited to Jabber due to the XML character nature. On a java
>> client we get this info when this character is sent:
>> Illegal XML character &#xb;
> Sending those via a chat/IM should no longer be possible anymore as of
> 2.6.something (Adium 1.3 still allows injecting those characters because
> it's using an older version of libpurple); we strip those characters out
> of messages when sending.
>> I was able to paste this character into my status and it took down
>> everyone in the company that was on the jabber server with a few
>> exceptions.
> Oops, yes.  Still possible to inject them via status messages.  Good catch!
> Other instances of this have been covered in various tickets (#5768,
> #6031, and #12170, probably others).
> The long and short of the issue is that XMPP specifies that
> clients/servers MUST disconnect on receiving invalid XML (ASCII control
> characters other than \t, \n, and \r, or encoded entities of said
> control characters are invalid in XML 1.0 -- my comments on #12170 link
> to the XMPP spec and draft replacement standard as well as the XML 1.0
> specification)
> Our parser correctly throws an error on invalid entities, and /most/
> servers will properly disconnect clients that send them (ejabberd,
> Google Talk, Prosody, M-Link, and /I think/ Tigase all do), but
> Openfire's parser doesn't (http://issues.igniterealtime.org/browse/OF-91)
> I think the fix (well, workaround) here is to perform the same
> sanitizing on the status message that we do on XMPP messages (there are
> probably other ways to induce this, though, like putting entities into
> the vCard or a bunch of other text input areas).

I don't think I've been able to reproduce this problem, but maybe I
don't understand it correctly.

Cory: So you're saying that if a user sends that character to a chat
room, then any Pidgin user in the chat room will get disconnected by
the jabber server?

Paul: And you're saying that the XMPP server should not allow a client
to send this character in the first place (it should disconnect the
client, instead)?  And recent versions of Pidgin don't allow sending
this character in IMs, but they do still allow sending this character
in status messages (and that should be changed)?

I tried typing <ctrl>+<shift>+u, then 013 as my status message and it
didn't seem to break anything with two accounts signed onto Google
Talk.  Is this server-dependent?  Am I using the right character
(ASCII character aka octal 013 aka decimal 11 aka hex 0x0B aka
"vertical tab")?


More information about the security mailing list