Openfire is an open source project. Every line of code we ship comes either from our public repositories or from clearly identified third-party dependencies. We have no reason to believe there is any undisclosed or malicious code in the project.
To maintain the quality and integrity of Openfire, we follow a number of established practices:
Transparent, reproducible builds - We use industry standard tooling to build Openfire from source, ensuring that anyone can reproduce our builds exactly as we do.
Automated testing - Every change runs through a comprehensive suite of automated unit and integration tests, catching regressions early.
Continuous integration - Our CI system builds and tests Openfire regularly, providing immediate feedback if something breaks.
Dependency management - We track and update third-party libraries to address vulnerabilities and maintain compatibility.
Open documentation - Our build instructions, plugin development guides, and deployment notes are all public, so the process is visible and verifiable.
Independent security audits - Openfire has, in the past, been reviewed by professional third-party security auditors, the most recent of which took place this year. While these reports are not public, any issues identified are addressed. No audit has ever uncovered a problem that would justify freezing the project or halting downloads.
If you have concerns-such as about the LaunchDaemon or parts of our packaging that arenât immediately clear-please provide specific, reproducible details (I have provided a check list thatâs usable for this in an earlier message). That will allow us to investigate effectively.
You are, of course, free to contact the German BSI if you feel it is necessary. Should they approach us, we will cooperate fully and provide complete access to our source code and build processes - which is, as I explained above, open and accessible for everyone in the first place. However, without verifiable evidence, there is no basis for quarantining the software or suspending its distribution.
you should read exactly before got entertained, but of course you did, because you cited correctly. How can you then misinterpret âknown codeâ as âknown bugâ?
If you assume that a server requires a LaunchDaemon and OpenFire is of this kind, why can users start and stop the service manually and at least for Mac and Linux but likely too for Windows?
Let us assume, that for the Linux version the single script start by executing the openfire.sh file in the bin folder forks some independent code, which keeps running the server software as some LaunchDaemon could do at MacOS, why does the openfire.sh not stop execution after successful launch of the server?
Let me teach you, that the Linux operation is continuous script execution and possible manual stop of the described and expected service by ctrl-C input to the terminal.
You are right, I do not know, whether the Linux version does not forks something undescribed and unexpected in the same way as the Mac version does likely by the LaunchDaemon, but I can tell you that the described and expected function at the Mac version operates the same way: started by the application start and stopped by the application stop. Anything forked and started to operate independently has not yet received any description and not any declaration of use. Neither from commenters before nor from you.
Please stop complaining and start searching for the real use of the LaunchDaemons activity.
Users have the option of using the LaunchDaemon (so the server starts automatically on boot) or launching the server manually via the script.
Would you like me to put those words into a search engine for you? To get you to a document like this? Iâm not sure what youâre asking for here.
Youâre damned right Iâm complaining. Youâre leaping to conclusions without the technical details to back it up, and wasting peopleâs time with that haste. TCP connections in a JVM process are nothing to do with a piece of XML that instructs a Mac to launch a process.
Slow down. Work out what youâre actually observing. Consider all of the possibilities, and what else you could learn from your system to inform the fuller picture. For example: Is a TCP connection attempt even a threat? If so, how? Whatâs the source of that connection? Whatâs receiving it? Does the receiver log, to indicate whether this is expected or unexpected? Is any bad action actually occuring? If so, exactly what is that? Can you follow it to the source?
Is it at all possible, given the gaps youâve shown, that you might not have the technical know-how to follow this investigation through to a conclusion with any certainty to it? Thatâs not an insult - Iâm no security researcher. I might know a few of the methods, but Iâve only identified one new vulnerability in my entire life, and I used BurpSuite to do it.
For a piece of software so complex as Openfire (note the spelling ) and with so many years of development, thereâs a practical certainty that undiscovered bugs exist. Itâs likely, given open ports and a significant dependency tree that undiscovered security vulnerabilities exist. If you can point at one, and provide a reproducible method, threat and impact, weâll absolutely look to address it.
And please, keep the tone towards this projectâs volunteers civil, or youâll be blocked from use of the forums.
We have not received the logs, plugin files, or other forensic data needed to confirm any security issue. Without that, we canât act on speculation.
Unless new, verifiable evidence is provided, we will consider this matter closed. The security of Openfire remains a priority, and any well-documented reports are always welcome through our established channels.
If there are still concerns about perceived inconsistencies in the macOS launcher or its behavior, I suggest opening a new discussion specifically on that topic. That will allow us to address it without conflating it with unsubstantiated security concerns.
Who controls, what is behind the starter software, which obviously can be loaded from the Internet?
Who controls, when this shall happen?
Hence, the upper research result is, that the MacOS version is able to install independently from user interaction whatever software the provider defines at every system launch by the LaunchDaemon. Because it can be arbitrary Java code, it might not even be related to any installed file. Hence, stopping the action probably will not leave any trace except of the potential open door shown above.
For the Linux version I could not identify anything similar. Can you confirm this?
Please provide a Mac version without such automated update possibility and this risk is gone.
As I have already switched to Linux-VM you can take your time for a good solution.
As long as you cannot totally exclude abuse of this installer operation putting the Mac version into quarantine and stopping from download is urgently recommended.
Thanks for taking the time to investigate this and write it up.
Iâll be honest though: your post is difficult to follow, because it mixes observations, assumptions and conclusions without clearly distinguishing them. That makes it hard for readers to know which parts are verified facts and which are speculation.
As I understand it, your key points are:
The macOS build ships more helper scripts (launchd integration, control scripts, etc.) than the Linux distribution.
The installer is created with install4j, which is capable of supporting auto-update.
From that, you worry that Openfire could automatically download and execute code from the internet.
That last step is where the conclusion doesnât hold. The presence of install4j runtime files does not mean auto-update is enabled. In fact, Openfireâs install4j configuration (which is part of the public source code) shows that auto-update is explicitly disabled. Anyone can confirm this by reviewing the configuration files in the source repository.
So while itâs fair to say the macOS package contains more scripts than Linux and uses install4j, there is no evidence that Openfire automatically downloads or executes remote code. The conclusion that the Mac installer is inherently unsafe or should be quarantined isnât supported by the facts.
Instead of assuming the worst, it would be more helpful to ask specific, verifiable questions (for example: what does this script do at startup? or is this install4j component actually active?). That allows others to give precise answers and avoids drawing conclusions that the evidence doesnât support.
sorry, but your telling is either wrong regarding the install4j status, or auto-updating was not the intention to keep the install4j power in use.
Please find a video about the installation process resulting to the LaunchDaemon, which is likely able to do whatever the server wants it to do, where updating is only one positive and useful possibility, but opens a lot of negative and user independent other possibilities, too.
This video tells about the hidden .install4j folder and this one tells about the openfire-service script code, which accesses and executes server provided code.
Please tell in the next comment that OpenFire team will stop distribution of this Mac version and will provide one, which will not exhibit any risk like this one told by removing the .install4j folder, the LauchDaemon, the openfire-service and the openfired script from installation.
Many thanks for your no got comprehension and support!
Iâve watched the videos you shared, but I donât yet see how they demonstrate an actual vulnerability. Could you clarify which part of the behavior shown creates a security risk, and under what conditions it could be exploited? If possible, it would be very helpful if you could show, in a new video, a concrete example of how the presumed vulnerability could be abused in practice.
InstallâActivate Launch Daemonâexecute opefire-serviceâload whatever is behind from install4j.org.jivesoftware.openfire.starter.ServerStarter313984128âexecute.
It looks, that the server of question is OpenFire / jivesoftware dependent. Please tell, for what purpose this activity is good for?
Sorry, I do not need to make anything more evident. If you do not remove this big open door of possible abuse, it is required to warn all OpenFire users about.
If there was any real abuse, and I am sure it was, do you not think that the trouble above has warned the abuser already? In this case do we expect to get the server operation reappearing? If no one tells about the use of the server code execution, what will people think about? Evidence of possibility is enough. Stopp it!
The Launch Daemon and ServerStarter component you mention appear to be part of Openfireâs normal startup process on macOS. Running the application as a system service/daemon is expected behavior and allows the server to run automatically, which is standard for this type of software.
Despite your detailed description, it is still not clear to me what the specific security concern is. If Openfire is not executed in a trusted environment (meaning the server files are not protected from unauthorized modification) then any potential issues related to these files are largely irrelevant, as a potential attacker would already have access to the system.
Even if the vulnerability seems obvious to you, please help us understand it by providing a demonstration or concrete example.
The framework does not considers active and running security attacks. Instead it considers vulnerabilities. Hence, the whole IT industry focuses vulnerabilities. You should follow.
Most vulnerabilities are related to external attack possibilities. The one I am reporting is about internal abuse possibilities.
openfire.starter.ServerStarter is Openfireâs server starter. The source code is available here.
Iâve reread that source code, and donât find any obvious avenues for weakness or external attack.
Regarding CSAF, thatâs a document format for information sharing in a machine readable format, where that document might include an advisory. In regards to vulnerabilities, perhaps you mean CVEs? Those are descriptions of actual vulnerabilities. Hereâs their glossary link. To disclose a vulnerability, weâd need demonstrate how it could be exploited. Do you have that information? I canât yet see a chain of events that leads to any compromise.
many thanks for your search efforts. Those questions arise from your report:
Are you sure that the routine, which you have found, is the one, which I have found in the script?
Indications of doubt:
Only a part of the longer naming looks equal to your code path.
The name at the end differs.
Why is the routine, which I have found install4j related, although yourâs is not?
Is your routine already part of installed code?
Is the code set, which is installed by the downloadable installer image complete?
If yes, why do you need any install4j code inside?
If no, what needs to be post installed via user invisible Internet access and
why is it needed to do a post install and
why is it useful to hide the action from the users?
If we assume, that any post install is reasonable, how do you assure, that the reasonable code is loaded and not something else by changing the content of the package, although package name likely needs to be kept for the operation?
If we remove directly after installation the install4j folder and the LaunchDaemonâs plist file and any script code in between, what reduction of function of OpenFire do you expect?
Regarding your question: CSAF is the method. CVEs are the resulting products.
Yes. I didnât rewrite all of it. The 313984128 at the end is a JVM thing (because youâre actually looking at an instance of a class, not the class itself).
Youâve misunderstood whatâs happening. This class doesnât invoke install4j. Nothing in a running Openfire server would. Install4j makes the installer. If memory serves, Install4j creates the launch daemon which calls the ServerStarter. That sounds logical right?
An installer puts the binaries onto the disk
It also sets up a launch daemon so that every time you boot your machine, the server starts
The bit of the server that starts the server is ServerStarter
Yes, the ServerStarter is part of Openfire. If you download the .tar.gz version of Openfire, itâs in ./lib/startup.jar - we know that because of the finalName in the pom, here.
Iâm not sure what youâre asking. Install4j is used to package a built version of Openfire into a DMG for macOS. Thatâs why itâs needed.
Thereâs no âinvisible internet accessâ required - you can test this yourself by installing the DMG with no internet connection.
If install4j gives you concerns, download the .tar.gz, or build from source. If you still want the XMPP server launching on startup, you can create your own launch daemon.
No. The other way around. You create a CVE, then you communicate it with a CSAF.
I hope this has been helpful in your learning about macOS, Java, security practices and other topics, but I think weâre at the point where youâve taken enough time on this topic without bringing any actual concerns. I thank you for your diligence, but youâll understand if we need to close this topic to allow our volunteers to retain focus on other matters.
today I did multiple testings with the MacOS version by dropping some of the installed items with those results:
Nothing dropped:
You are right. The server is already started after machine restart and admin console can be used.
Accordingly, there is Java process running.
Dropping the LaunchDaemon (plist).
After restart:
no admin console,
no java process.
OpenFire.app can be used to start and stop the OpenFire server.
Dropping install4j folder:
OpenFire.app is not operating any more.
The OpenFire Server can still be started and stopped via the openfire.sh script equally to the Linux method of operation.
At that point it is questionable what happens, after machine start has already started OpenFire via LaunchDaemon, what starts the OpenFire.app? From the listings shown, it looks like a start process, what should have been done already. However this is not so important, I guess.
If anyone has doubts about uncontrolled server start and unknown possibilities of the install4j system, dropping it and the LaunchDaemon is possible and manually controlled start/stop may reduce the risk of abuse.
Until now I did not found any misbehaviour of the Linux version. Hence, one may recommend this way of use for the MacOS version, too.
Let us hope for the best and close this item. Many thanks for the discussion!
) and with so many years of development, thereâs a practical certainty that undiscovered bugs exist. Itâs likely, given open ports and a significant dependency tree that undiscovered security vulnerabilities exist. If you can point at one, and provide a reproducible method, threat and impact, weâll absolutely look to address it.