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:

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 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/TH5FF4AMOB5VO4FUS7TRJIFBP7ISQDCY/



_______________________________________________
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/3WY4NXNYOKWN5YX5YDXGOGS2KZVK3IIS/
_______________________________________________
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/FHJWJHADUF4VLQVBK4LRGYQMD5ZMNBU5/


--

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA

sbonazzo@redhat.com   

Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.