oVirt and log4j vulnerability
Can an oVirt developer comment about the log4j vulnerability - is oVirt's use of log4j vulnerable? -- Chris Adams <cma@cmadams.net>
Hi, I think this only affects between 2.0 <= and <= 2.14.1 (https://bugzilla.redhat.com/show_bug.cgi?id=2030932) ovirt engine uses 1.2.17 So I don't think this hits ovirt 4.4 Greetings Klaas On 12/11/21 22:53, Chris Adams wrote:
Can an oVirt developer comment about the log4j vulnerability - is oVirt's use of log4j vulnerable?
Are you sure? lsof -n -P |grep log4j java 2977 892943 EE-Manage ovirt 213r REG 253,0 301418 2071533 /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar seems vulnerable to me. ovirt 2977 1.1 11.9 3955136 1954500 ? Sl Dec03 157:37 ovirt-engine --add-modules java.se -server -XX:+TieredCompilation -Xms1462M -Xmx1462M -Xss1M -Djava.awt.headless=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djsse.enableSNIExtension=false -Dresteasy.preferJacksonOverJsonB=true -Djackson.deserialization.whitelist.packages=org,com,java,javax -Dcom.redhat.fips=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/ovirt-engine/dump -Djava.util.logging.manager=org.jboss.logmanager -Dlogging.configuration=file:///var/lib/ovirt-engine/jboss_runtime/config/ovirt-engine-logging.properties -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.default.config=ovirt-engine -Djboss.home.dir=/usr/share/ovirt-engine-wildfly -Djboss.server.base.dir=/usr/share/ovirt-engine -Djboss.server.data.dir=/var/lib/ovirt-engine -Djboss.server.log.dir=/var/log/ovirt-engine -Djboss.server.config.dir=/var/lib/ovirt-engine/jboss_runtime/config -Djboss.server.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp -Djboss.controller.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp -jar /usr/share/ovirt-engine-wildfly/jboss-modules.jar -mp /usr/share/ovirt-engine-wildfly-overlay/modules:/usr/share/ovirt-engine/modules/common:/usr/share/ovirt-engine-extension-aaa-jdbc/modules:/usr/share/ovirt-engine-extension-aaa-ldap/modules:/usr/share/ovirt-engine-wildfly/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -c ovirt-engine.xml rpm -qf /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar ovirt-engine-wildfly-23.0.2-1.el8.x86_64 I believe we should start engine with -Dlog4j2.formatMsgNoLookups=true for mitigation but I cannot find where to apply this for jboss. maybe directly in /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py somewhere in _engineArgs G On 12/12/2021 10:25, Klaas Demter wrote:
Hi,
I think this only affects between 2.0 <= and <= 2.14.1 (https://bugzilla.redhat.com/show_bug.cgi?id=2030932)
ovirt engine uses 1.2.17
So I don't think this hits ovirt 4.4
Greetings
Klaas
On 12/11/21 22:53, Chris Adams wrote:
Can an oVirt developer comment about the log4j vulnerability - is oVirt's use of log4j vulnerable?
_______________________________________________ Users mailing list --users@ovirt.org To unsubscribe send an email tousers-leave@ovirt.org Privacy Statement:https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct:https://www.ovirt.org/community/about/community-guidelines/ List Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/TH5FF4AMOB5VO4...
Hi, no, I am not sure :) but if it's only the log4j-api package it should not be vulnerable either: https://issues.apache.org/jira/browse/LOG4J2-3201?focusedCommentId=17456962&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17456962 But I am guessing for a real answer you need to wait for a maintainer of the package :) Greetings Klaas On 12/12/21 15:48, Kapetanakis Giannis wrote:
Are you sure?
lsof -n -P |grep log4j
java 2977 892943 EE-Manage ovirt 213r REG 253,0 301418 2071533 /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar
seems vulnerable to me. ovirt 2977 1.1 11.9 3955136 1954500 ? Sl Dec03 157:37 ovirt-engine --add-modules java.se -server -XX:+TieredCompilation -Xms1462M -Xmx1462M -Xss1M -Djava.awt.headless=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djsse.enableSNIExtension=false -Dresteasy.preferJacksonOverJsonB=true -Djackson.deserialization.whitelist.packages=org,com,java,javax -Dcom.redhat.fips=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/ovirt-engine/dump -Djava.util.logging.manager=org.jboss.logmanager -Dlogging.configuration=file:///var/lib/ovirt-engine/jboss_runtime/config/ovirt-engine-logging.properties -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.default.config=ovirt-engine -Djboss.home.dir=/usr/share/ovirt-engine-wildfly -Djboss.server.base.dir=/usr/share/ovirt-engine -Djboss.server.data.dir=/var/lib/ovirt-engine -Djboss.server.log.dir=/var/log/ovirt-engine -Djboss.server.config.dir=/var/lib/ovirt-engine/jboss_runtime/config -Djboss.server.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp -Djboss.controller.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp -jar /usr/share/ovirt-engine-wildfly/jboss-modules.jar -mp /usr/share/ovirt-engine-wildfly-overlay/modules:/usr/share/ovirt-engine/modules/common:/usr/share/ovirt-engine-extension-aaa-jdbc/modules:/usr/share/ovirt-engine-extension-aaa-ldap/modules:/usr/share/ovirt-engine-wildfly/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -c ovirt-engine.xml
rpm -qf /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar ovirt-engine-wildfly-23.0.2-1.el8.x86_64
I believe we should start engine with -Dlog4j2.formatMsgNoLookups=true for mitigation but I cannot find where to apply this for jboss.
maybe directly in /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py somewhere in _engineArgs
G
On 12/12/2021 10:25, Klaas Demter wrote:
Hi,
I think this only affects between 2.0 <= and <= 2.14.1 (https://bugzilla.redhat.com/show_bug.cgi?id=2030932)
ovirt engine uses 1.2.17
So I don't think this hits ovirt 4.4
Greetings
Klaas
On 12/11/21 22:53, Chris Adams wrote:
Can an oVirt developer comment about the log4j vulnerability - is oVirt's use of log4j vulnerable?
_______________________________________________ Users mailing list --users@ovirt.org To unsubscribe send an email tousers-leave@ovirt.org Privacy Statement:https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct:https://www.ovirt.org/community/about/community-guidelines/ List Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/TH5FF4AMOB5VO4...
_______________________________________________ Users mailing list --users@ovirt.org To unsubscribe send an email tousers-leave@ovirt.org Privacy Statement:https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct:https://www.ovirt.org/community/about/community-guidelines/ List Archives:https://lists.ovirt.org/archives/list/users@ovirt.org/message/3WY4NXNYOKWN5Y...
So far we can't confirm whether oVirt engine systems are affected or not: the oVirt infra team is digging into this. I can confirm that ovirt-engine-wildfly is shipping a log4j version which is affected by the vulnerability and we are monitoring Wildfly project so we'll be able to ship an update as soon as a fix will be available (we are just repackaging the binary build they provide). But I got no report so far confirming if the way we run Wildfly exposes the vulnerable system to potential attackers yet. Il giorno lun 13 dic 2021 alle ore 13:27 Klaas Demter <klaasdemter@gmail.com> ha scritto:
Hi,
no, I am not sure :)
but if it's only the log4j-api package it should not be vulnerable either:
But I am guessing for a real answer you need to wait for a maintainer of the package :)
Greetings
Klaas
On 12/12/21 15:48, Kapetanakis Giannis wrote:
Are you sure?
lsof -n -P |grep log4j
java 2977 892943 EE-Manage ovirt 213r REG 253,0 301418 2071533 /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar
seems vulnerable to me.
ovirt 2977 1.1 11.9 3955136 1954500 ? Sl Dec03 157:37 ovirt-engine --add-modules java.se -server -XX:+TieredCompilation -Xms1462M -Xmx1462M -Xss1M -Djava.awt.headless=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djsse.enableSNIExtension=false -Dresteasy.preferJacksonOverJsonB=true -Djackson.deserialization.whitelist.packages=org,com,java,javax -Dcom.redhat.fips=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/ovirt-engine/dump -Djava.util.logging.manager=org.jboss.logmanager -Dlogging.configuration= file:///var/lib/ovirt-engine/jboss_runtime/config/ovirt-engine-logging.properties -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.default.config=ovirt-engine -Djboss.home.dir=/usr/share/ovirt-engine-wildfly -Djboss.server.base.dir=/usr/share/ovirt-engine -Djboss.server.data.dir=/var/lib/ovirt-engine -Djboss.server.log.dir=/var/log/ovirt-engine -Djboss.server.config.dir=/var/lib/ovirt-engine/jboss_runtime/config -Djboss.server.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp -Djboss.controller.temp.dir=/var/lib/ovirt-engine/jboss_runtime/tmp -jar /usr/share/ovirt-engine-wildfly/jboss-modules.jar -mp /usr/share/ovirt-engine-wildfly-overlay/modules:/usr/share/ovirt-engine/modules/common:/usr/share/ovirt-engine-extension-aaa-jdbc/modules:/usr/share/ovirt-engine-extension-aaa-ldap/modules:/usr/share/ovirt-engine-wildfly/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -c ovirt-engine.xml
rpm -qf /usr/share/ovirt-engine-wildfly/modules/system/layers/base/org/apache/logging/log4j/api/main/log4j-api-2.14.0.jar ovirt-engine-wildfly-23.0.2-1.el8.x86_64
I believe we should start engine with -Dlog4j2.formatMsgNoLookups=true for mitigation but I cannot find where to apply this for jboss.
maybe directly in /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py somewhere in _engineArgs
G
On 12/12/2021 10:25, Klaas Demter wrote:
Hi,
I think this only affects between 2.0 <= and <= 2.14.1 ( https://bugzilla.redhat.com/show_bug.cgi?id=2030932)
ovirt engine uses 1.2.17
So I don't think this hits ovirt 4.4
Greetings
Klaas
On 12/11/21 22:53, Chris Adams wrote:
Can an oVirt developer comment about the log4j vulnerability - is oVirt's use of log4j vulnerable?
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TH5FF4AMOB5VO4...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/3WY4NXNYOKWN5Y...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/FHJWJHADUF4VLQ...
-- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*
On Mon, Dec 13, 2021 at 1:38 PM Sandro Bonazzola <sbonazzo@redhat.com> wrote:
So far we can't confirm whether oVirt engine systems are affected or not: the oVirt infra team is digging into this. I can confirm that ovirt-engine-wildfly is shipping a log4j version which is affected by the vulnerability and we are monitoring Wildfly project so we'll be able to ship an update as soon as a fix will be available (we are just repackaging the binary build they provide). But I got no report so far confirming if the way we run Wildfly exposes the vulnerable system to potential attackers yet.
If I understood correctly reading here: https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-lo... you are protected by the RCE if java is 1.8 and greater than 1.8.121 (released on 2017) " If the server has Java runtimes later than 8u121, then it is protected against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”(see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html). " It is not clear to me if it means that Java 11 (and 17) also maintained that setting. In one of my oVirt with 4.4.8 it seems that engine is using java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64 package Gianluca
On 13. 12. 2021, at 14:04, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Mon, Dec 13, 2021 at 1:38 PM Sandro Bonazzola <sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>> wrote: So far we can't confirm whether oVirt engine systems are affected or not: the oVirt infra team is digging into this. I can confirm that ovirt-engine-wildfly is shipping a log4j version which is affected by the vulnerability and we are monitoring Wildfly project so we'll be able to ship an update as soon as a fix will be available (we are just repackaging the binary build they provide). But I got no report so far confirming if the way we run Wildfly exposes the vulnerable system to potential attackers yet.
We concluded the investigation and we believe we are not affected, while a vulnerable log4j is being shipped (and will be fixed by wildfly/jboss) we are not using this functionality in any of or components. Wildfly reimplements log4j and we use that instead, all other usage is in compile time, unit tests. We also use log4j 1.x but without the JMSAppender in runtime. Thanks to MartinP for confirmation Thanks, michal
If I understood correctly reading here: https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-lo... <https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell>
you are protected by the RCE if java is 1.8 and greater than 1.8.121 (released on 2017)
" If the server has Java runtimes later than 8u121, then it is protected against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”(see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html <https://www.oracle.com/java/technologies/javase/8u121-relnotes.html>). "
It is not clear to me if it means that Java 11 (and 17) also maintained that setting. In one of my oVirt with 4.4.8 it seems that engine is using java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64 package
Gianluca _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/WH3WZLRM6NYC7M...
Once upon a time, Michal Skrivanek <michal.skrivanek@redhat.com> said:
We concluded the investigation and we believe we are not affected, while a vulnerable log4j is being shipped (and will be fixed by wildfly/jboss) we are not using this functionality in any of or components. Wildfly reimplements log4j and we use that instead, all other usage is in compile time, unit tests. We also use log4j 1.x but without the JMSAppender in runtime. Thanks to MartinP for confirmation
Thanks for digging into this and checking. -- Chris Adams <cma@cmadams.net>
On Mon, December 13, 2021 8:04 am, Gianluca Cecchi wrote:
If I understood correctly reading here: https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-lo...
you are protected by the RCE if java is 1.8 and greater than 1.8.121 (released on 2017)
Do you mean 1.8.0.121? For example, my system has: java-1.8.0-openjdk-headless-1.8.0.252.b09-2.el7_8.x86_64 -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Mon, Dec 13, 2021 at 2:37 PM Derek Atkins <derek@ihtfp.com> wrote:
On Mon, December 13, 2021 8:04 am, Gianluca Cecchi wrote:
If I understood correctly reading here:
https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-lo...
you are protected by the RCE if java is 1.8 and greater than 1.8.121 (released on 2017)
Do you mean 1.8.0.121? For example, my system has:
java-1.8.0-openjdk-headless-1.8.0.252.b09-2.el7_8.x86_64
-derek
Yes, what the link refers to as 8u121: https://www.oracle.com/java/technologies/javase/8u121-relnotes.html Your version: 8u252 (or anyway based on it). On my 4.4.8 engine I have java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el8_4.x86_64 but I have also java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64 that is what ovirt-engine uses, based on: [root@ovmgr1 ovirt-engine]# ll /proc/$(pidof ovirt-engine)/fd | grep jvm lr-x------. 1 ovirt ovirt 64 Sep 24 09:02 3 -> /usr/lib/jvm/java-11-openjdk-11.0.12.0.7-0.el8_4.x86_64/lib/modules [root@ovmgr1 ovirt-engine]# Gianluca
On Mon, Dec 13, 2021 at 2:46 PM Derek Atkins <derek@ihtfp.com> wrote:
On Mon, December 13, 2021 8:04 am, Gianluca Cecchi wrote:
If I understood correctly reading here:
https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-lo...
you are protected by the RCE if java is 1.8 and greater than 1.8.121 (released on 2017)
Do you mean 1.8.0.121? For example, my system has:
java-1.8.0-openjdk-headless-1.8.0.252.b09-2.el7_8.x86_64
If you are still on oVirt 4.3, which is using OpenJDK 1.8, then you should have installed java-1.8.0-openjdk-1.8.0.312.b07-1.el7_9.x86_64. If you are on oVirt 4.4, which is using OpenJDK 11, then you should have installed java-11-openjdk-headless-11.0.13.0.8-3.el8_5.x86_64
-derek
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/32PPOVQZRSIMCQ...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
participants (8)
-
Chris Adams -
Derek Atkins -
Gianluca Cecchi -
Kapetanakis Giannis -
Klaas Demter -
Martin Perina -
Michal Skrivanek -
Sandro Bonazzola