Another question, a sign of exploitation would be a log like this:
2021-12-10 17:14:56,207 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://127.0.0.1/a]. javax.naming.CommunicationException: 127.0.0.1:389 [Root exception is java.net.ConnectException: Connection refused (Connection refused)]
That was taken from this blog: Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package | LunaSec
We are not sure, how easy it is. Personally, looking at the callstats logs, I do not see any information coming from clients to be printed. This is my assumption, and we worked yesterday on the issue without any assumptions, so we can protect everybody 100%.
Thank you so much for the quick reply! And also thank you for your work remediating this vulnerability.
Dear Team,
Have you seen the next CVE related to log4j v2?
Second Log4j Vulnerability (CVE-2021-45046)
Could we expect an another update soon?
Many thanks!
I used this as a workaround:
zip -q -d /usr/share/jitsi-videobridge/lib/log4j-core-2.*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
to remove Jndilookup.class from any log4j-core-2.*.jar file
Then restart the server.
Note: The log4j version 2.15, distributed with jitsi, is vulnerabile.
Hi,
CVE-2021-45046 does not affect the jitsi components, because they don’t use any of the related features in PatternLayout (jvb, jigasi). We’re in the process of updating to 2.16.0 in any case.
Are callstats enabled by default in a standard installation (i.e. following the self-hosting guide)? Also, where can I verify if callstats are enabled in my installation for jigasi / jitsi-videobridge respectively?
No, in order to enable it you need to create an account on callstats and it is paid service for monitoring webrtc calls.
Hi,
I’m sure you’re focused on the log4j problem which occupies us all at the moment.
I see that my jitsi instance is now on 2.15 but the latest recommandation is to update on 2.17.
Is there a roadmap about that ?
Log4j was removed from the dependencies chore: Remove all use of log4j. by bgrozev · Pull Request #1786 · jitsi/jitsi-videobridge · GitHub
If you want, you can update to the latest from unstable.
I’m using the Debian-like packages, and log4l is still not fixed there!
Is the fix scheduled there soon?
And more importantly, is there a plan to make a proper Debian package? Having an embedded copy of log4j in videobidge is really bad practice. The Debian packages liblog4j* have been fixed almost immediately upon CVE disclosure. Videobridge really should use this, rather than ship its own copy, which is not updated!
Yep, log4j was dropped in jvb in latest packages. You can update to unstable if you need it.
The source code repo is not shipping the lib, but is using the maven repo, this cannot happen for binary packages though. As we ship reproducible builds, with all dependencies. For reproducible builds you cannot download different library versions between runs.
@damencho, do you have a timing estimate on when a stable version is estimated to be released? I see the last unstable version appears to be built on Dec 28th. We have issues with security compliance not allowing log4j 2.15 or 2.16 to be used and they are not pleased about an unstable version as a workaround. Thanks kindly and appreciate all the hard work to dig out from this mess!
There is no ETA at the moment, normally after meet.jit.si release we do that. Probably we will do one in the following weeks.
The latest stable is safe with all the issues. The new release will just remove log4j completely.
If you are not using callstats, a temporary workaround will be to just delete log4j binary from /usr/share and run it like that, I think that should work.
No. If you AREN’T using callstats, then it’s safe to delete because it’s unused. The dependency will be gone altogether in the next stable update.
Sorry for being obtuse 
But if I am not using callstats - why do I need to remove log4j? I understood that Jitsi is only affected, if I do use callstats…
You don’t need to. Some users are using tools for scanning files on system, and even if that is not used those are being flagged …
We will push new stable today or tomorrow that completely removes the log4j.
