Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#12170 closed rejected_patch (duplicate)

Pidgin repeatedly disconnects from jabber, if there're messages containing  in a conference

Reported by: sergem Owned by: deryni
Milestone: Component: XMPP
Version: 2.7.0 Keywords: xmpp jabber disconnect chat conference
Cc:

Description

Recently I've got under the casual DoS attack in jabber conference, when one of participants pasted a message, that contained  in its body.

Steps to reproduce an attack:

  1. Connect to Jabber/XMPP conference with i.e. psi
  2. Paste and send a buffer, that contains ASCII char 1
  3. See all libpurple clients disconnected

If the conference sends last messages after the reconnect (as most do), no pidgin is able to connect to this conference any more. I suppose the attack can be done in many other way (by setting a conference title or status message with similar character, or just sending a private message).

That time I had to find a fast solution, and I found one. Attached patch skips all such messages, that cause disconnects. I tested it for a few weeks already.

It is not perfect but it works. Feel free to make any suggestions.

Attachments (1)

pidgin-2.7.0-xml-invalid-char-fix.patch (1.3 KB) - added by sergem 9 years ago.
a patch that fixes this problem

Download all attachments as: .zip

Change History (6)

Changed 9 years ago by sergem

a patch that fixes this problem

comment:1 Changed 9 years ago by darkrain42

  • Resolution set to duplicate
  • Status changed from new to closed
  • Type changed from defect to rejected_patch

Closed as duplicate of #6031.
This has been reported multiple times (#6031 just happens to be the one I found via Google first). It's a bug in Openfire (and possibly other servers, but that's the only one I'm aware of), which MUST NOT accept malformed XML (although Psi probably shouldn't be allowed to generate it -- libpurple no longer generates IMs with ASCII control characters, and I know Gajim also strips them out).

Both RFC 3920 and its almost-finished-with-last-call replacement draft-ietf-xmpp-3920bis say that an entity MUST disconnect on receiving invalid XML

Quoting from draft-ietf-xmpp-3920bis 11.3:

   An XMPP entity MUST NOT generate data that is not XML-well-formed.
   An XMPP entity MUST NOT accept data that is not XML-well-formed;
   instead it MUST return an <xml-not-well-formed/> stream error and
   close the stream over which the data was received.}}}

comment:2 Changed 9 years ago by darkrain42

I just checked to make sure there's an open ticket for this on Openfire's issue tracker (it's been around for a while, but better to have it there than not): upstream ticket OF-91

comment:3 follow-up: Changed 9 years ago by sergem

It's a bug in Openfire, which MUST NOT accept malformed XML

My report is not about a bug in Openfire. It's about a bug in libpurple, that allows others to make a DoS-attack against it. You're explaining why this problem appeared (because of bug in openfire). I don't mind about that. But it's still a problem of pidgin, that is not present in other jabber clients, and that CAN be fixed in libpurple. Then why not fixing it?

Yes, it APPEARED because of bug in Openfire (or any other server). But this IS A BUG in libpurple, that can be exploited using the Openfire bug.

Are there any reasons not to fix it?

An XMPP entity MUST NOT generate data that is not XML-well-formed. ...

BTW, why these 4 characters (&#1;) form a message, that is not XML-well-formed?

comment:4 in reply to: ↑ 3 ; follow-up: Changed 9 years ago by darkrain42

Replying to sergem:

Are there any reasons not to fix it?

Yes, fixing it is in violation of the RFC (and is a pretty ugly hack, resulting in "missing" messages).

An XMPP entity MUST NOT generate data that is not XML-well-formed. ...

BTW, why these 4 characters (&#1;) form a message, that is not XML-well-formed?

&#1; represents the ASCII control character 0x01 (SOH - Start of Heading).

From the XML 1.0 specification:

[66]   	CharRef	   ::=   	'&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';'	[WFC: Legal Character]

WFC: Legal Character:

Well-formedness constraint: Legal Character
Characters referred to using character references must match the production for Char.

Char:

[2]   	Char	   ::=   	#x9 | #xA | #xD |
                                [#x20-#xD7FF] | [#xE000-#xFFFD] |
                                [#x10000-#x10FFFF]
                                /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

As you can see, ASCII control characters other than 0x09 (Horizontal Tab), 0x0A (newline), and 0x0D (Carriage Return) are not allowed as a Char, and therefore cannot be present in an entity-encoded fashion, either.

comment:5 in reply to: ↑ 4 Changed 9 years ago by sergem

Replying to darkrain42:

Yes, fixing it is in violation of the RFC ...

Thank you for the detailed explanation.

(and is a pretty ugly hack, resulting in "missing" messages).

Well, that's the problem that can be fixed. :)

Anyway, I understand you.

Let's hope that this bug will be fixed in all the servers and all other clients before someone decide to use it for killing pidgins/adiums/etc.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!