powered by Jive Software

Bug: disconnect when client is missing 'from' attribute + RFC violation

Sending the following stanza will cause a client disconnection:

Where ‘proxy.example.com’ is the built-in openfire socks5 proxy. The error (from the openfire logs) is:

2007.09.19 11:24:38 org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:341) Could not route packet

java.lang.IllegalArgumentException: Illegal JID:

at org.xmpp.packet.JID.init(JID.java:384)

at org.xmpp.packet.JID.(JID.java:219)

at org.jivesoftware.openfire.filetransfer.proxy.FileTransferProxy.handleIQ(FileTra nsferProxy.java:126)

at org.jivesoftware.openfire.filetransfer.proxy.FileTransferProxy.process(FileTran sferProxy.java:349)

Adding a ‘from’ attribute (regardless of whether that from attribute is correct) to the iq stanza prevents the disconnect. However, there is still a violation of rfc3920, section 9.2.3: ‘An entity that receives an IQ request of type “get” or “set” MUST reply with an IQ response of type “result” or “error” (the response MUST preserve the ‘id’ attribute of the request).’. Openfire does not respond at all.

Hey Hawke,

Thanks for the bug report. I filed http://www.igniterealtime.org/issues/browse/JM-1125 and checked in a fix for it. BTW, the problem in your packet is that the activate element has no text in it. That is triggering an exception that at the end ends up closing your connection.

Regards,

– Gato

I think you’re mistaken; even with the activate tag removed entirely, the error still occurs. While on the other hand adding a bogus ‘from’ attribute to the iq tag prevents the disconnect, even leaving the empty activate tag.

Hey Hawke,

Do not remove the activate element but instead add a text to it

– Gato

Ah yes, that does indeed prevent the disconnect.

However, reading XEP-0065 I cannot find any place that it specifies that activate may not be empty. Can you point out to me what I’m missing?

Hey Hawke,

In the XEP-0065: SOCKS5 Bytestreams you can see in the section 4.9 an example where activate specifies the JID of the other party. And in the section 6.1 you see that activate has to be present. Anyway, I agree that section 4.9 does not explicitly say that it MUST contain a JID but you can infer it from the context.

Regards,

– Gato

Thank you for the pointer; the text “including an <activate/> element whose XML character data specifies the full JID of the Target.” does indeed imply that it’s a must.

I assume the fix you commited was to make openfire return an error for those cases, rather than simply dropping the connection?

Hey Hawke,

That’s correct. The problem that you found was in fact about how Openfire deals with internal errors while processing IQ packets of any type. The server will now return an IQ of type error instead of closing the connection.

Regards,

– Gato

Great, thanks a lot!

Hi Gato,

in section 12 one can see that the packet is valid, putting text inside of …

So I really wonder if I do not understand the schema or if activate MUST be empty. Or is this is a bugus XEP?

LG