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")

1 post - 1 participant

Read full topic

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")

1 post - 1 participant

Read full topic

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")

1 post - 1 participant

Read full topic

Gajim 1.5.4 comes with a reworked file transfer interface, better URL detection, message selection improvements, and many fixes under the hood. Thank you for all your contributions!

What’s New

Gajim’s interface for sending files has been reworked, and should be much easier to use now. For each file you’re about to send, Gajim will generate a preview. This way, you can avoid sending the wrong file to somebody. Regardless of how you start a file transfer, be it drag and drop, pasting a screen shot, or simply clicking the share button, you’ll always be able to check what you’re about to send.

Gajim’s new file transfer interface

More Changes

• Performance: Chat history is now displayed quicker
• Support for Jingle XTLS has been dropped, since it hasn’t been standardized
• geo:-URIs are now prettier (thanks, @mjk )
• Dependencies: pyOpenSSL has been replaced by python-cryptography

Fixes

• Fixes for message selection
• Improvements for recognizing URLs ( @mjk )
• Many fixes to improve Gajim’s usability

Over 20 issues have been fixed in this release. Have a look at the changelog for a complete list.

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab .

Gajim 1.5.4 comes with a reworked file transfer interface, better URL detection, message selection improvements, and many fixes under the hood. Thank you for all your contributions!

What’s New

Gajim’s interface for sending files has been reworked, and should be much easier to use now. For each file you’re about to send, Gajim will generate a preview. This way, you can avoid sending the wrong file to somebody. Regardless of how you start a file transfer, be it drag and drop, pasting a screen shot, or simply clicking the share button, you’ll always be able to check what you’re about to send.

Gajim’s new file transfer interface

More Changes

• Performance: Chat history is now displayed quicker
• Support for Jingle XTLS has been dropped, since it hasn’t been standardized
• geo:-URIs are now prettier (thanks, @mjk )
• Dependencies: pyOpenSSL has been replaced by python-cryptography

Fixes

• Fixes for message selection
• Improvements for recognizing URLs ( @mjk )
• Many fixes to improve Gajim’s usability

Over 20 issues have been fixed in this release. Have a look at the changelog for a complete list.

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab .

Gajim 1.5.4 comes with a reworked file transfer interface, better URL detection, message selection improvements, and many fixes under the hood. Thank you for all your contributions!

What’s New

Gajim’s interface for sending files has been reworked, and should be much easier to use now. For each file you’re about to send, Gajim will generate a preview. This way, you can avoid sending the wrong file to somebody. Regardless of how you start a file transfer, be it drag and drop, pasting a screen shot, or simply clicking the share button, you’ll always be able to check what you’re about to send.

Gajim’s new file transfer interface

More Changes

• Performance: Chat history is now displayed quicker
• Support for Jingle XTLS has been dropped, since it hasn’t been standardized
• geo:-URIs are now prettier (thanks, @mjk )
• Dependencies: pyOpenSSL has been replaced by python-cryptography

Fixes

• Fixes for message selection
• Improvements for recognizing URLs ( @mjk )
• Many fixes to improve Gajim’s usability

Over 20 issues have been fixed in this release. Have a look at the changelog for a complete list.

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab .

Earlier today, we have released version 2.4.0 of the Openfire Monitoring Service plugin. This plugin adds both statistics, as well as message archiving functionality to Openfire.

In this release, compatibility with future versions of Openfire is added. A bug that affects MSSQL users has been fixed, and the dreaded “Unable to save XML properties” error message has been resolved. A few other minor tweaks have been added.

As always, your instance of Openfire should automatically display the availability of the update. Alternatively, you can download the new release of the plugin at the Monitoring plugin’s archive page .

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

Earlier today, we have released version 2.4.0 of the Openfire Monitoring Service plugin. This plugin adds both statistics, as well as message archiving functionality to Openfire.

In this release, compatibility with future versions of Openfire is added. A bug that affects MSSQL users has been fixed, and the dreaded “Unable to save XML properties” error message has been resolved. A few other minor tweaks have been added.

As always, your instance of Openfire should automatically display the availability of the update. Alternatively, you can download the new release of the plugin at the Monitoring plugin’s archive page .

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic

Earlier today, we have released version 2.4.0 of the Openfire Monitoring Service plugin. This plugin adds both statistics, as well as message archiving functionality to Openfire.

In this release, compatibility with future versions of Openfire is added. A bug that affects MSSQL users has been fixed, and the dreaded “Unable to save XML properties” error message has been resolved. A few other minor tweaks have been added.

As always, your instance of Openfire should automatically display the availability of the update. Alternatively, you can download the new release of the plugin at the Monitoring plugin’s archive page .

For other release announcements and news follow us on Twitter

1 post - 1 participant

Read full topic