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.grzy...@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é <j...@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.grzy...@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 <steven.huyp...@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 <
> > e...@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.grzy...@gmail.com>
> > >>>> Sent: Friday, December 10, 2021 1:43:00 PM
> > >>>> To: dev@karaf.apache.org <dev@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 <e...@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.grzy...@gmail.com>
> > >>>>> Gesendet: Friday, December 10, 2021 12:20:02 PM
> > >>>>> An: ops4j-announcem...@googlegroups.com <
> > >>>>> ops4j-announcem...@googlegroups.com>; Karaf Dev <
> > >> dev@karaf.apache.org
> > >>>> ;
> > >>>>> d...@felix.apache.org <d...@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
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
