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.assun...@exploitsys.com <mailto:joao.assun...@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 <pkmccull...@gmail.com
<mailto:pkmccull...@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é <j...@nanthrax.net
<mailto:j...@nanthrax.net>> wrote:
It makes sense. As it’s for a short period.
Regards
JB
> Le 23 déc. 2021 à 19:19, Paul Spencer
<paulspen...@mindspring.com <mailto:paulspen...@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
<j...@nanthrax.net <mailto:j...@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
<paulspen...@mindspring.com <mailto:paulspen...@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é <j...@nanthrax.net
<mailto:j...@nanthrax.net>> wrote:
>>>>
>>>> Then create your own custom distro upgrading pax logging.
>>>>
>>>>> Le 23 déc. 2021 à 17:23, Paul Spencer
<paulspen...@mindspring.com <mailto:paulspen...@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é <j...@nanthrax.net
<mailto:j...@nanthrax.net>> wrote:
>>>>>>
>>>>>> Upgrade to Karaf 4.2.13.
>>>>>>
>>>>>>>> Le 23 déc. 2021 à 17:02, Paul Spencer
<paulspen...@mindspring.com <mailto:paulspen...@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>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
