You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Paul McCulloch <pk...@gmail.com> on 2022/01/04 10:49:34 UTC
Re: Updated mitigation for Log4JShell in Karaf 4.2.x and 4.3.x since setting log4j2.formatMsgNoLookups is a insufficient mitigation measure
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é <jb...@nanthrax.net> wrote:
> It makes sense. As it’s for a short period.
>
> Regards
> JB
>
> > Le 23 déc. 2021 à 19:19, Paul Spencer <pa...@mindspring.com> 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 <jb...@nanthrax.net>
> 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 <pa...@mindspring.com> 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é <jb...@nanthrax.net> wrote:
> >>>>
> >>>> Then create your own custom distro upgrading pax logging.
> >>>>
> >>>>> Le 23 déc. 2021 à 17:23, Paul Spencer <pa...@mindspring.com>
> 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é <jb...@nanthrax.net> wrote:
> >>>>>>
> >>>>>> Upgrade to Karaf 4.2.13.
> >>>>>>
> >>>>>>>> Le 23 déc. 2021 à 17:02, Paul Spencer <pa...@mindspring.com>
> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
Re: Updated mitigation for Log4JShell in Karaf 4.2.x and 4.3.x since setting log4j2.formatMsgNoLookups is a insufficient mitigation measure
Posted by Łukasz Dywicki <lu...@code-house.org>.
Just remember to restart system after update. ;-)
Also, you can override files on the disk and start with clean caches.
Best,
Łukasz
On 4.01.2022 13:29, João Assunção wrote:
>
> 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: joao.assuncao@exploitsys.com <ma...@exploitsys.com>
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com <http://www.exploitsys.com>
>
>
>
>
> On Tue, Jan 4, 2022 at 10:49 AM Paul McCulloch <pkmcculloch@gmail.com
> <ma...@gmail.com>> 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é <jb@nanthrax.net
> <ma...@nanthrax.net>> wrote:
>
> It makes sense. As it’s for a short period.
>
> Regards
> JB
>
> > Le 23 déc. 2021 à 19:19, Paul Spencer
> <paulspencer@mindspring.com <ma...@mindspring.com>>
> 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
> <jb@nanthrax.net <ma...@nanthrax.net>> 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
> <paulspencer@mindspring.com <ma...@mindspring.com>>
> 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é <jb@nanthrax.net
> <ma...@nanthrax.net>> wrote:
> >>>>
> >>>> Then create your own custom distro upgrading pax logging.
> >>>>
> >>>>> Le 23 déc. 2021 à 17:23, Paul Spencer
> <paulspencer@mindspring.com <ma...@mindspring.com>>
> 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é <jb@nanthrax.net
> <ma...@nanthrax.net>> wrote:
> >>>>>>
> >>>>>> Upgrade to Karaf 4.2.13.
> >>>>>>
> >>>>>>>> Le 23 déc. 2021 à 17:02, Paul Spencer
> <paulspencer@mindspring.com <ma...@mindspring.com>>
> 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 <https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: Updated mitigation for Log4JShell in Karaf 4.2.x and 4.3.x since setting log4j2.formatMsgNoLookups is a insufficient mitigation measure
Posted by João Assunção <jo...@exploitsys.com>.
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: joao.assuncao@exploitsys.com
Mobile: +351 916968984
Phone: +351 211933149
Web: www.exploitsys.com
On Tue, Jan 4, 2022 at 10:49 AM Paul McCulloch <pk...@gmail.com>
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é <jb...@nanthrax.net> wrote:
>
>> It makes sense. As it’s for a short period.
>>
>> Regards
>> JB
>>
>> > Le 23 déc. 2021 à 19:19, Paul Spencer <pa...@mindspring.com> 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 <jb...@nanthrax.net>
>> 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 <pa...@mindspring.com>
>> 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é <jb...@nanthrax.net> wrote:
>> >>>>
>> >>>> Then create your own custom distro upgrading pax logging.
>> >>>>
>> >>>>> Le 23 déc. 2021 à 17:23, Paul Spencer <pa...@mindspring.com>
>> 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é <jb...@nanthrax.net> wrote:
>> >>>>>>
>> >>>>>> Upgrade to Karaf 4.2.13.
>> >>>>>>
>> >>>>>>>> Le 23 déc. 2021 à 17:02, Paul Spencer <
>> paulspencer@mindspring.com> 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
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>>