Hi,
one of my users accidentally found an critical bug, either in Openfire or the Kraken IM Gateway Plugin. However, it does also happen with pyICQt. I talked with Daniel Henninger (Kraken developer and former Openfire developer), he says:
I’m 99% sure that’s an issue with Openfire’s internal routing.
Since neither Daniel nor me have time to go more into this, I’m posting this issue here in public.
Setup (not sure if important)
- there are two local, and one external user. I’m calling them userA, userB and userC.
- userA and B are both using the ICQ transport and have subscribed each other via ICQ and via Jabber.
- userC is an external ICQ user in mutual subscription with userA. In my case he is using an Transport on another server.
Steps to reproduce
Open XML direct input for userA, and send the following packet:
<message to="something.icq.yourserver.org" id="Test001">
<body>Test</body>
</message>
(where ‘icq.yourserver.org’ is your transports component JID)
visible Results
- userA and B cannot send ICQ messages, but userA can receive messages from userC.
- normal Jabber messages between userA and B are delayed. After one minute or so normal messages work normal again.
- after an restart of Kraken everyone can talk to everyone again
- Openfire takes 100% CPU.
**Conclusion
**
When using Raptor with Flood-Detection enabled, I didn’t detect that 100% CPU Problem. Probably there is somewhere an packet loop which is causing that high CPU load. Raptor does detect that flood and can break the loop by block the sender temporary. Also it can log the user who was causing the problem. (Actually Raptor was designed for exactly that use case.)
Since pyICQt is also delicately for this “attack” it’s possible it’s a bug in Openfire. However, since pyICQt was originally written by the same author, maybe it’s just the same bug.
I tried to write a simple “do nothing” plugin to reproduce this issue without Kraken. I had no success, it seems to be more complicated. Plugin source code as follows:
package org.jivesoftware.openfire.plugin; import org.jivesoftware.openfire.container.Plugin;
import org.jivesoftware.openfire.container.PluginManager;
import org.jivesoftware.util.Log;
import org.xmpp.packet.*;
import org.xmpp.component.*;
import java.io.File;
import java.util.*; public class Crash implements Component, Plugin {
private ComponentManager componentManager; public void initializePlugin(PluginManager manager, File pluginDirectory) { try {
componentManager = ComponentManagerFactory.getComponentManager();
componentManager.addComponent("crash", this); } catch (Exception e) { Log.error(e); }
Log.info("Crash-Plugin started.");
} public void destroyPlugin() {
Log.info("Crash-Plugin stoping.");
try {
componentManager.removeComponent("crash");
componentManager = null;
}
catch (Exception e) {
Log.error(e);
}
} public synchronized void initialize(JID jid, ComponentManager componentManager) { }
public synchronized void start() { }
public synchronized void shutdown() { }
public void processPacket(Packet packet) { Log.info("Crash-Plugin: \n" + packet.toString()); }
public String getName() { return "Crash"; } public String getDescription() { return "Bug demonstration plugin"; }
}
Other information (not sure if important)
- Openfire 3.6.3
- Kraken last SVN (from 2009-04-21)
- MySQL database
- CentOS 5.3 Linux
- using Psi Jabber Client, 0.13-dev-rev2