I think the correct versions of pax logging would be 1.11.13. And the "patching" can be made with two updates:
bundle:update org.ops4j.pax.logging.pax-logging-api <path or URL to pax-logging-api-1.11.13.jar> bundle:update org.ops4j.pax.logging.pax-logging-log4j2 <path or URL to pax-logging-log4j2-1.11.13.jar> Regards, João Email: [email protected] Mobile: +351 916968984 Phone: +351 211933149 Web: www.exploitsys.com On Tue, Jan 4, 2022 at 10:49 AM Paul McCulloch <[email protected]> wrote: > You can uninstall the affected pax logging bundles & install versions > where the issue is resolved: > > bundle:uninstall org.ops4j.pax.logging.pax-logging-log4j2 > bundle:uninstall org.ops4j.pax.logging.pax-logging-api > bundle:install -l 8 -s mvn:org.ops4j.pax.logging/pax-logging-api/1.11.11 > bundle:install -l 8 -s mvn:org.ops4j.pax.logging/pax-logging-log4j2/1.11.11 > > However the affected version may get reinstalled (though won't be wired as > far as I can tell) when other features are installed.To avoid this, and to > ensure that a 'clean' doesn't undo the upgrade I found the following to > work (in addition to upgrading the affected bundles). > > * replace the affected JARs in the /system repo with empty JARs (so that > they won't be downloaded from a central maven repo) > * add the new logging JARs to the /system repo > * Modify etc/startup.properties to use the new versions of pax logging > (only affects 'clean') > * Create etc/blacklisted.properties with content > > pax-logging-api;type=bundle;url=mvn:org.ops4j.pax.logging/pax-logging-api/1.9.1 > > pax-logging-log4j2;type=bundle;url=mvn:org.ops4j.pax.logging/pax-logging-log4j2/1.9.1 > To prevent any attempt to load the old bundles by features which > explicitly request them > > Paul > > > On Thu, 23 Dec 2021 at 18:40, JB Onofré <[email protected]> wrote: > >> It makes sense. As it’s for a short period. >> >> Regards >> JB >> >> > Le 23 déc. 2021 à 19:19, Paul Spencer <[email protected]> a >> écrit : >> > >> > JB, >> > Karaf upgrades will be done, just not during the holiday breaks when >> compliance resources are scarce. Mitigating the issue by setting >> log4j2.formatMsgNoLookups and removing the JndiLoookup.class will allow the >> current environment to run while upgrades are be run through each >> customer's compliance and deployment processes. >> > >> > Thank you and the Karaf team for rapidly releasing updated versions of >> Karaf to address the CVE. The updated Karaf will be will incorporated into >> our products and pushed through the release and deployment process as >> quickly as possible. >> > >> > Paul Spencer >> > >> >> On Dec 23, 2021, at 12:42 PM, Jean-Baptiste Onofre <[email protected]> >> wrote: >> >> >> >> It would mitigate only the JNDI part, not the other CVE (about the >> lookup). >> >> >> >> Anyway, it’s a good workaround. >> >> >> >> I don’t understand why you don’t want to upgrade to a new version. >> It’s exactly the purpose of the new releases to address CVE. >> >> Else, why we would do new releases if you are stuck with old versions. >> Log4j did couple of new releases to address the CVE issue, so it’s worth to >> update. >> >> >> >> Regards >> >> JB >> >> >> >>>> Le 23 déc. 2021 à 18:37, Paul Spencer <[email protected]> >> a écrit : >> >>> >> >>> JB, >> >>> Aymen Furter suggested the following: >> >>> >> >>> $ cd karaf-directory >> >>> $ zip -q -d $(find . | grep pax-logging-log4j2 | grep jar) >> org/apache/logging/log4j/core/lookup/JndiLookup.class >> >>> $ zip -q -d $(grep -rlnw . -e "pax-logging-log4j2" | grep >> "data/cache/bundle" | grep jar) >> org/apache/logging/log4j/core/lookup/JndiLookup.class >> >>> >> >>> >> >>> This looks like a reasonable short term workaround that is relatively >> easy to implement. Relative to the Karaf and its services, do you see any >> potential problems with the workaround? >> >>> >> >>> >> >>> Paul Spencer >> >>> >> >>>> On Dec 23, 2021, at 12:17 PM, JB Onofré <[email protected]> wrote: >> >>>> >> >>>> Then create your own custom distro upgrading pax logging. >> >>>> >> >>>>> Le 23 déc. 2021 à 17:23, Paul Spencer <[email protected]> >> a écrit : >> >>>>> >> >>>>> JB, >> >>>>> As stated earlier, upgrading Karaf is not an option in the short >> term. >> >>>>> >> >>>>> Paul Spencer >> >>>>> >> >>>>> >> >>>>>> On Dec 23, 2021, at 11:21 AM, JB Onofré <[email protected]> wrote: >> >>>>>> >> >>>>>> Upgrade to Karaf 4.2.13. >> >>>>>> >> >>>>>>>> Le 23 déc. 2021 à 17:02, Paul Spencer < >> [email protected]> a écrit : >> >>>>>>> >> >>>>>>> In light of the updated mitigation for the Log4JShell published >> by Log4J[1], specifically "zip -q -d log4j-core-*.jar >> org/apache/logging/log4j/core/lookup/JndiLookup.class", the insufficient >> mitigation measure of setting system property log4j2.formatMsgNoLookups, >> and the presents of JndiLookup.class in the pax-logging-log4j2 jar. What is >> the suggested mitigation for Karaf 4.2.x and Karaf 4.3.x when upgrading >> Karaf is not an option in the short term? >> >>>>>>> >> >>>>>>> *** >> >>>>>>> * Example from Karaf 4.2.9 >> >>>>>>> **** >> >>>>>>> [user@localhost karaf]$ zip -sf >> ./system/org/ops4j/pax/logging/pax-logging-log4j2/1.11.6/pax-logging-log4j2-1.11.6.jar >> | grep JndiLookup >> >>>>>>> org/apache/logging/log4j/core/lookup/JndiLookup.class >> >>>>>>> [user@localhost karaf]$ >> >>>>>>> >> >>>>>>> Paul Spencer >> >>>>>>> >> >>>>>>> [1] >> https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228 >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> > >> >>
