Jabber Server bug

Contenido archivado

El contenido de la web se encuentra archivado y no se podrá crear nuevo contenido. Más información.

Tagged:

We have identified a bug in the server concerning < and > characters in nicks in MUC chatrooms and normal conference chatrooms. The behaviour is not identical, but it shares a common base.

The examples here are for a MUC chatroom, chatroom@muc.jabber.org

Here, one user (user1@jabber.org) enters the chatroom with nick |<USER1>|

OUT(1,user1@jabber.org/tkabber):
<presence to='chatroom@muc.jabber.org/|&lt;USER1&gt;|'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

As we can see, the client correctly encodes and sends the nick.

IN(1,user1@jabber.org/tkabber):
<presence from='chatroom@muc.jabber.org/|&amp;lt;USER1&gt;|'
        to='user1@jabber.org/tkabber'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item role='participant'
        affiliation='none'/>
  </x>
</presence>

Here problems start. The nick has been either half-decoded or decoded and half-reencoded, or something of the like, before being recoded again for transmission back to the client. The &amp;lt; is the result of encoding again &lt; but &gt; remains unchanged.

Now the nick seems to be internally stored inside the server as |&lt;USER1>| which leads to everything ending up with that nick (but everything is re-encoded for transmission, so really it just causes annoyance because of the nick change, and some artifacts due to the client not knowing that it has changed, mainly that the client thinks that someone else is talking.)

The rest of the conversation is carried out normally, but everybody in the chatroom sees |&lt;USER1>|

A second user (user2@jabber.org) tries to enter the chatroom.

Now here's the really annoying problem:

The user expands the jabber browser item for the chatroom and the xml stream gets corrupted and restarts. Here's why:

OUT(1,user2@jabber.org/tkabber):
<iq id='7'
    to='chatroom@muc.jabber.org'
    type='get'>
  <item xmlns='jabber:iq:browse'/>
</iq>'

The client asks for the channel browse.

IN(1,user2@jabber.org/tkabber):
<iq from='jabberes@muc.jabber.org'
      id='7'
      to='user2@jabber.org/tkabber'
      type='result'>
  <item version='0.5.3-20031015a'
      name='chatroom'
      xmlns='jabber:iq:browse'
      type='public'
      category='conference'>
    <item jid='jabberes@muc.jabber.org/Moderator'
      name='Moderator'
      type='client'
      category='moderator'/>
    <item jid='jabberes@muc.jabber.org/|&lt;USER1>|'
      name='|&lt;USER1>|'
      type='client'
      category='user'/>
    <ns>http://jabber.org/protocol/muc</ns>
  </item>
</iq>

The server responds with user-list. Now here the user is transmitted literally as |&lt;USER1>| and the > confuses the XML parser.

I think the solution(s) would be to remove that extra semi-enconding step at the beginning that is obviously wrong, and to make sure everything is encoded before output (the userlist misses that step.)

BTW, this might have something to do with the fact that in this context this:

<tag> &lt; > </tag>

is valid since the > doesn't close any tag, so it isn't encoded, but the < would seem to open one, so that's why it is encoded. Since in the userlist the names would be inside a parameter, not a tag, it would need to be the opposite:

<tag name='< &gt;' />

so as to not confuse the parser.

IMHO everything should be encoded e.g. <tag> &lt; &gt; </tag> so as to avoid confusion.

Comentarios

please check on conference.jabber.ru

<aleksey>looks like bug of conference component

<aleksey>try on conference.jabber.ru

<aleksey>it seems conference.jabber.ru work fine, so this is bug of conference-v0.4 and mu-c

<aleksey>or maybe in jabberd14 library

<badlop>does jabber.ru use ejabberd?

<aleksey>conference.jabber.ru

<aleksey>jabber.ru will use it soon :)

Jabber.ru is the same

It still doesn't work.

conference.jabber.ru is a MUC and behaves exactly like jabber.org MUCs.

MUCs let you enter with a <> nick, and no one else can enter after you, plus any operation regarding a change of nick hangs the client, plus the nick shows that ugly < .

Normal chatrooms just hang the client when you try to enter with a <> nick.