Some of you might already have followed along with the discussion on this in the open_chat chatroom, but: the Ignite Realtime community now has its own Mastodon service at toot.igniterealtime.org! This service is graciously sponsored by Free Solutions Sàrl - a big thank you to Claude and his team!

1200×627 26.3 KB

The idea is to have a Mastodon service with accounts from like-minded people with regards to open source / open standards real time collaboration. That way, both our local as well as federated timelines should become more applicable to us, as the users of this service, as compared to one of the larger, generic servers that are out there. Also, decentralizing by moving away from some of those gigantic services is a Good Thing©®!

We are inviting our community members to join toot.igniterealtime.org! If you don’t have a Mastodon account yet, or if you want an additional one, or want to migrate your existing account, please join us!

At least for now, this server is not accepting public sign-ups. While we are gaining experience with running a Mastodon service, we will limit new accounts to people from the community that we recognize. This will largely be based on the trust levels that software running our forum is assigning to people.

When you sign up on our Mastodon service, please use the same mail address that you used to sign up to our forum, so that we can cross-reference who’s who. It helps if you fill out your forum username in the answer to the “Why do you want to join?” question that’s part of the application. The approval process is manual, so please allow for some time for that to happen. If you think that we’ve missed your request (Mastodon doesn’t always send out notifications, it appears), please let us know by reaching out in the forum, or in the open_chat chatroom!

We are looking forward to hearing from you in the Fediverse!

The fantastic folks behind Jitsi have discovered a Denial of Service (DoS) vulnerability in Smack (JSA-2022-0002, JSA-2022-0003), which is possible if a combination of Smack components is used. The root of the vulnerability is interesting because it is due to a countermeasure against DoS attacks, namely FEATURE_SECURE_PROCESSING of the Java API for XML Processing (JAXP).

The DoS is possible because the older XMPPTCPConnection implementation of Smack parses the XMPP stream as one large XML document. Suppose the connection instance uses a parser where FEATURE_SECURE_PROCESSING is enabled. In that case, it is easy for an attacker to craft a stanza that triggers one of the various limits imposed by FEATURE_SECURE_PROCESSING, causing an exception, leaving the parser in an unrecoverable state, and closing the connection.

This vulnerability was relatively recently introduced in Smack with the addition of the support for JAXP’s Streaming API for XML (StaX) parser. Historically, Smack only used XPP3 as XML pull parser. The default implementation of XPP3 is a fast, lightweight, and, to the best of our knowledge, secure parser. XPP3 is used, for example, by Android. However, with version 4.4.0 (SMACK-591), Smack gained support for using Java’s Streaming API for XML (StAX) in addition to XPP3, to facilitate code-reuse on Java SE platforms and avoiding the XPP3 dependency.

So this DoS is possible if the XMPP connection is of type XMPPTCPConnection and if the Smack connection instance uses a StAX parser for XMPP parsing.

On a related note, Smack’s newer modular connection architecture is not affected by this, because it splits the individual top-level XMPP stream elements and parses them as standalone document. The splitting is done very early in the input processing step by XmlSplitter (of jxmpp), which also enforces size limits for the XML elements. Therefore, the DoS is not possible over connections that are established via Smack’s modern ModularXmppClientToServerConnection.

If you are affected, then the following countermeasures are possible:

1. Relax the FEATURE_SECURE_PROCESSING_LIMITS
2. Switch to XPP3 (smack-xmlparser-xpp3)
3. Use ModularXmppClientToServerConnection

Option A has the drawback that it is only possible to relax the limits globally. That is, it will affect XML processing regardless if Smack or some other component performs it. If you still want to go down that route, then

System.setProperty("jdk.xml.entityExpansionLimit", "0")
System.setProperty("jdk.xml.maxOccurLimit", "0")
System.setProperty("jdk.xml.elementAttributeLimit", "0")
System.setProperty("jdk.xml.totalEntitySizeLimit", "0")
System.setProperty("jdk.xml.maxXMLNameLimit", "524288")
System.setProperty("jdk.xml.entityReplacementLimit", "0")