This is also true in regards to the new and updated CVE-2021-45105 discovered from log4j over the last few days.
See CVE-2021-45105: https://logging.apache.org/log4j/2.x/security.html => OpenMeetings is using logback as the underlying logging framework. CVE-2021-45105 does not affect OpenMeetings. Thanks Sebastian Sebastian Wagner Director Arrakeen Solutions, OM-Hosting.com http://arrakeen-solutions.co.nz/ https://om-hosting.com - Cloud & Server Hosting for HTML5 Video-Conferencing OpenMeetings <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> On Fri, 17 Dec 2021 at 14:49, Maxim Solodovnik <solomax...@gmail.com> wrote: > OM is not affected :) > > You still can add "-Dlog4j2.formatMsgNoLookups=true" just-in-case :) > > from mobile (sorry for typos ;) > > > On Fri, Dec 17, 2021, 05:50 seba.wag...@gmail.com <seba.wag...@gmail.com> > wrote: > >> This is 6.2.0 which hasn't changed in months. Can you be sure that >>> there isn't a problem in 6.2.0 ? >> >> The logging framework OpenMeetings is using is not log4j. But we are >> using SLF4J. >> >> The files you highlighted are dependencies of OpenMeetings. Those "could" >> use log4j, they invoke log4j APIs. E.g. hazelcast can be configured to use >> either log4j or slf4j. However OpenMeetings is not using log4j. >> >> OpenMeetings is using SLF4j. SLF4j provides a bridge for older >> dependencies that rely on log4j. It also doesn't use log4j as the >> underlying logging framework itself. >> >> See this detailed write up of the impact of this specific vulnerability >> on SLF4j, especially the section about using logback: >> http://slf4j.org/log4shell.html >> >> Quote: >> >> *Does a similar vulnerability exist in logback?Logback does NOT offer a >> lookup mechanism at the message level. Thus, it is deemed safe with respect >> to CVE-2021-44228.* >> >> On a high level the explanation is that if you look into the actual CVE >> of log4j you will notice that the vulnerability is around a configuration >> passed into log4j: >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046. So by not >> using log4j but logback as the underlying framework the SLF4j community is >> pretty save. >> >> => OpenMeetings is using logback. You can also see that if you go to >> $OM_HOME/webapps/openmeetings/WEB-INF/classes/logback-config.xml >> Which is this file: >> https://github.com/apache/openmeetings/blob/master/openmeetings-web/src/main/webapp/WEB-INF/classes/logback-config.xml >> >> In summary: OpenMeetings is not using log4j. SLF4j and the way how >> OpenMeetings is configured is also not referring to log4j but using >> logback. >> >> So there is little chance for anybody to use this specific vulnerability >> (CVE-2021-44228) to expose or execute malicious functionality on an >> OpenMeetings instance. >> >> Thanks, >> Sebastian >> >> Sebastian Wagner >> Director Arrakeen Solutions, OM-Hosting.com >> http://arrakeen-solutions.co.nz/ >> https://om-hosting.com - Cloud & Server Hosting for HTML5 >> Video-Conferencing OpenMeetings >> >> <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> >> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> >> >> >> On Fri, 17 Dec 2021 at 08:42, <i...@bureau-de-poste.net> wrote: >> >>> A search on our open meetings server (6.2.0) for apache log4j >>> vulnerabilities: >>> >>> find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null >>> >>> produced these results: >>> >>> com/hazelcast/logging/Logger.class:Binary file (standard input) >>> matches >>> com/hazelcast/logging/Log4j2Factory$Log4j2Logger.class:Binary file >>> (standard input) matches >>> com/hazelcast/logging/Log4j2Factory.class:Binary file (standard >>> input) matches >>> META-INF/maven/com.hazelcast/hazelcast/pom.xml:Â Â Â Â Â Â >>> <version>${log4j2.version}</version> >>> META-INF/maven/com.hazelcast/hazelcast/pom.xml:Â Â Â Â Â Â >>> <version>${log4j2.version}</version> >>> io/netty/util/internal/logging/Log4J2Logger$2.class:Binary file >>> (standard input) matches >>> io/netty/util/internal/logging/Log4J2Logger.class:Binary file >>> (standard input) matches >>> io/netty/util/internal/logging/Log4J2LoggerFactory.class:Binary file >>> (standard input) matches >>> io/netty/util/internal/logging/Log4J2Logger$1.class:Binary file >>> (standard input) matches >>> io/netty/util/internal/logging/InternalLoggerFactory.class:Binary >>> file (standard input) matches >>> com/mchange/v2/log/MLog$1.class:Binary file (standard input) matches >>> com/mchange/v2/log/log4j2/MLogAppender.class:Binary file (standard >>> input) matches >>> com/mchange/v2/log/log4j2/Log4j2MLog$Log4jMLogger.class:Binary file >>> (standard input) matches >>> com/mchange/v2/log/MLogClasses.class:Binary file (standard input) >>> matches >>> com/mchange/v2/log/log4j2/Log4j2MLog.class:Binary file (standard >>> input) matches >>> >>> >>> META-INF/maven/slf4j-configuration.properties:org.apache.logging.slf4j.Log4jLoggerFactory >>> org.apache.maven.cli.logging.impl.Log4j2Configuration >>> org/apache/maven/cli/logging/impl/Log4j2Configuration$1.class:Binary >>> file (standard input) matches >>> org/apache/maven/cli/logging/impl/Log4j2Configuration.class:Binary >>> file (standard input) matches >>> >>> This is 6.2.0 which hasn't changed in months. Can you be sure that >>> there isn't a problem in 6.2.0 ? >>> >>> Best, >>> >>> >>> Ed >>> >>> Le 2021-12-13 01:50, Maxim Solodovnik a écrit : >>> > Yes, >>> > We are not affected >>> > >>> > To get most updated version you can use latest SNAPSHOT :) >>> > >>> > from mobile (sorry for typos ;) >>> > >>> > On Mon, Dec 13, 2021, 04:21 Thomas Scholzen <tschol...@buche17.de> >>> > wrote: >>> > >>> >> Hi Sebastian, >>> >> >>> >> thank you for your assessment and quick response. >>> >> >>> >> Best regards, >>> >> Thomas >>> >> >>> >> Am 12.12.21 um 22:05 schrieb seba.wag...@gmail.com: >>> >> >>> >> Afaik we are not using the native log4j library. I think the >>> >> vulnerability is only in the actual log4j.jar file. >>> >> >>> >> log4j-over-slf4j is merely a bridge that mimics log4j APIs in order >>> >> to redirect the log stream into slf4j without rewriting the existing >>> >> log4j logging statements. The bridge ensures old dependencies that >>> >> have not been migrated to SLF4J can work with Openmeetings. >>> >> >>> >> So OpenMeetings is not using or distributing the native log4j JAR >>> >> library. Also the Tomat version we are using that bundles >>> >> OpenMeetings into a Java Servlet Container is not affected since >>> >> it's not using the native log4j jar file. >>> >> >>> >> So as far as I can see this vulnerability should not impact >>> >> OpenMeetings. >>> >> >>> >> However OpenMeetings regularly ships updates with the latest >>> >> libraries and dependencies, so if you are not using the latest >>> >> version, you should update. There have been other CVE's fixed in >>> >> recent versions. >>> >> >>> >> Thanks >>> >> Sebastian >>> >> >>> >> Sebastian Wagner >>> >> >>> >> Director Arrakeen Solutions, OM-Hosting.com >>> >> http://arrakeen-solutions.co.nz/ >>> >> >>> >> https://om-hosting.com - Cloud & Server Hosting for HTML5 >>> >> Video-Conferencing OpenMeetings >>> >> [1] [2] >>> >> >>> >> On Mon, 13 Dec 2021 at 07:29, Thomas Scholzen <tschol...@buche17.de> >>> >> wrote: >>> >> >>> >> Openmeetings has, among others, the following dependencies: >>> >> >>> >> log4j-over-slf4j-1.7.32.jar >>> >> slf4j-api-1.7.32.jar >>> >> jcl-over-slf4j-1.7.32.jar >>> >> >>> >> Does anyone know, whether these are affected by the log4j >>> >> vulnerability CVE-2021-44228 and have to be updated? >>> >> >>> >> Thanks, >>> >> Thomas >>> > >>> > >>> > Links: >>> > ------ >>> > [1] >>> > >>> https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url >>> > [2] >>> > >>> https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url >>> >>
