Open Realtime.
Ignite Realtime is the community site for the users and developers of open source Real Time Communications projects like Openfire, Smack, Spark, and Pàdé. Your involvement is helping to change the open RTC landscape.
Open Realtime.
Ignite Realtime is the community site for the users and developers of open source Real Time Communications projects like Openfire, Smack, Spark, and Pàdé. Your involvement is helping to change the open RTC landscape.
A few months ago, we published details about an important security vulnerability in Openfire that is identified as CVE-2023-32315.
To summarize: Openfire’s administrative console (the Admin Console), a web-based application, was found to be vulnerable to a path traversal attack via the setup environment. This permitted an unauthenticated user to access restricted pages in the Openfire Admin Console reserved for administrative users.
Leveraging this, a malicious actor can gain access to all of Openfire, and, by extension (through installing custom plugins), much of the infrastructure that is used to run Openfire. The Ignite Realtime community has made available new Openfire releases in which the issue is addressed, and published various mitigation strategies for those who cannot immediately apply an update. Details can be found in the security advisory that we released back in May.
In the last few days, this issue has seen a considerable increase in exposure: there have been numerous articles and podcasts that discuss the vulnerability. Many of these seem to refer back to a recent blogpost by Jacob Banes at Vulncheck.com, and those that do not seem to include very similar content.
Many of these articles point out that there’s a “new way” to exploit the vulnerability. We indeed see that there are various methods being used, in the wild, in which this vulnerability is abused. Some of these methods leave less traces than others, but the level of access that can be obtained through each of these methods is pretty similar (and, sadly, similarly severe).
Given the renewed attention, we’d like to make clear that there is no new vulnerability in Openfire. The issue, solutions and mitigations that are documented in the original security advisory are still accurate and up to date.
Malicous actors use a significant amount of automation. By now, it’s almost safe to assume that your instance has been compromised if you’re running an unpatched instance of Openfire that has its administrative console exposed to the unrestricted internet. Tell-tale signs are high CPU loads (of crypto-miners being installed) and the appearance of new plugins (which carry the malicious code), but this by no means is true for every system that’s compromised.
We continue to urge everyone to update Openfire to its last release, and carefully review the security advisory that we released back in May, to apply applicable mitigations where possible.
For other release announcements and news follow us on Twitter and Mastodon.
I have been recently working on a proprietary Openfire commercial plugin for Openfire that integrates XMPP with Azure Communication Services (ACS).
This plugin adds support for a whole range of modern web service connections to Openfire/XMPP via the embedded Jetty web server in a different way to the traditional persistent client XMPP session over TCP/5222 or Bosh/7443 or Websockets/7443 used by native binary clients.
It uses :
- JWTs (JSON Web Tokens) instead of traditional username/passwords combined with Web Authentication and Web Credentials to authenticate user requests and manage the user permissions and entitlements that apply for the request or entitlement.
- REST APIs to make requests and receive immediate responses.
- Server Sent Events (SSE) and
- Web-Push to push events to users when they are online or offline.
A user has a singleton xmpp session in Openfire that is created on demand and removed when it expires. This single user session can have many active REST and SSE connections depending on how many browsers tabs, browser windows or browser instances are connected to Openfire from applications in web pages opened on behalf of the user.
The xmpp session has the full feature set of an XMPP client that is based on Smack/Spark. It also has User Interface (UI) consisting of web-components that can bind directly to Spark features. For example, a contacts roster widget and a chat conversation widget. that work independent of each other and can be hosted in different web pages or different browsers but end up pointing at the same xmpp session.
A fully working XMPP client can be constructed in a web page with minimal HTML and JavaScript.
Over the next few weeks and months in my spare time, I will be extracting the open source aspects of the commercial plugin in to a new Openfire plugin I have aptly named SparkWeb.
Please post any comments or feedback if you want to get involved or want to influence the development of this community plugin,. Now is the time to get your ideas and suggestions in.
For other release announcements and news follow us on Twitter and Mastodon.
The Ignite Realtime Community is pleased to announce the first release of Galene plugin for Openfire
Galene is technically an audio/video SFU like Jitsi, however it handles a different use case from Jitsi. While Jitsi does audio/video conferencing very well with bi-directional media streams for an equal number of speakers and listeners, Galene does webinars and lectures much better with single uni-drectional streams for very few speakers and a larger number of listeners.
This plugin hosts a Galene server and also implements an XEP for in-band SFU sessions that I am currently working on. This XEP is used by the Pàdé client and the Galene ConverseJS community plugin. for supporting audio/video in webinars and lectures.
For other release announcements and news follow us on Twitter and Mastodon.
The Ignite Realtime community is happy to announce a new release of the Jabber Browsing plugin for Openfire.
This is a plugin for the Openfire Real-time Communications server. It provides an implementation for service discovery using the jabber:iq:browse namespace, as specified in XEP-0011: Jabber Browsing. Note that this feature is considered obsolete! The plugin should only be used by people that seek backwards compatibility with very old and very specific IM clients.
This release is a maintenance release. It adds translations and fixes one bug. More details are available in the changelog.
Your instance of Openfire should automatically display the availability of the update in the next few hours. Alternatively, you can download the new release of the plugin at the Jabber Browsing plugin archive page.
If you have any questions, please stop by our community forum or our live groupchat.
For other release announcements and news follow us on Twitter and Mastodon.
The Ignite Realtime community is happy to announce a new release of the Agent Information plugin for Openfire.
This plugin implements the XEP-0094 ‘Agent Information’ specification for service discovery using the jabber:iq:agents namespace. Note that this feature is considered obsolete! The plugin should only be used by people that seek backwards compatibility with very old and very specific IM clients.
This release is a maintenance release. It adds translations and fixes one bug. More details are available in the changelog.
Your instance of Openfire should automatically display the availability of the update in the next few hours. Alternatively, you can download the new release of the plugin at the Agent Information plugin archive page.
If you have any questions, please stop by our community forum or our live groupchat.
For other release announcements and news follow us on Twitter and Mastodon.
In the community
Recent Discussions
Pritesh Desai in "Monitoring Plugin Message Archive is not working when I used that from the Android device"
Amarnath Janapati in "NPE while newSessionId creating in Jetty server"
азамат Омар in "Smack client delivery only empty (null) message"
herman1 in "No org.igniterealtime.spark packages on Maven"
GCox in "Spark User info"