Fwd: Instant disconnect vulnerability

[Paul Aurich]

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).

<snip/>

> Cory McIntire cPanel, Inc. - Quality Assurance 

Thanks,
~Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20100813/03ab2acd/attachment.pgp>