Re: Significant security vulnerability discovered in Log4j

[Steven Smith]

Also please see https://github.com/macports/macports-ports/pull/13361 


> On Dec 14, 2021, at 6:47 PM, Nils Breunese  wrote:
> 
> A couple of hours ago 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 
>  was made 
> public, which states that the previous mitigations of upgrading to Log4J 
> 2.15.0 or setting system/environment properties is longer enough. The 
> recommended solution is upgrading to Log4J 2.16.0. If that is not possible, 
> it is recommended to at least remove the JndiLookup class from the log4j-core 
> JAR (e.g. zip -q -d log4j-core-*.jar 
> org/apache/logging/log4j/core/lookup/JndiLookup.class).



smime.p7s
Description: S/MIME cryptographic signature

Re: Significant security vulnerability discovered in Log4j

[Steven Smith]

Thank you for posting!

Please see https://github.com/macports/macports-ports/pull/13353 
.

> On Dec 14, 2021, at 6:47 PM, Nils Breunese  wrote:
> 
> A couple of hours ago 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 
>  was made 
> public, which states that the previous mitigations of upgrading to Log4J 
> 2.15.0 or setting system/environment properties is longer enough. The 
> recommended solution is upgrading to Log4J 2.16.0. If that is not possible, 
> it is recommended to at least remove the JndiLookup class from the log4j-core 
> JAR (e.g. zip -q -d log4j-core-*.jar 
> org/apache/logging/log4j/core/lookup/JndiLookup.class).



smime.p7s
Description: S/MIME cryptographic signature

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Arjun Salyan  wrote::

>> On 12-Dec-2021, at 3:27 PM, Joshua Root  wrote:
>> 
>> Not all ports have installed file information available, but the web app can 
>> search the ones that do:
>> 
>> 
> 
> I identified an issue with the way we were updating our search index. That 
> has been fixed and now this page shows 17 ports, instead of 5.

Thanks for fixing! For Log4J only log4j-core-* is relevant, and 
https://ports.macports.org/search/?installed_file=log4j-core= only shows the 
ports we already previously identified.

A couple of hours ago 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 was made public, 
which states that the previous mitigations of upgrading to Log4J 2.15.0 or 
setting system/environment properties is longer enough. The recommended 
solution is upgrading to Log4J 2.16.0. If that is not possible, it is 
recommended to at least remove the JndiLookup class from the log4j-core JAR 
(e.g. zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class).

Nils.

Re: Significant security vulnerability discovered in Log4j

[Arjun Salyan]

> On 12-Dec-2021, at 3:27 PM, Joshua Root  wrote:
> 
> Not all ports have installed file information available, but the web app can 
> search the ones that do:
> 
> 

I identified an issue with the way we were updating our search index. That has 
been fixed and now this page shows 17 ports, instead of 5.

Re: Significant security vulnerability discovered in Log4j

[Steven Smith]

Please see https://github.com/macports/macports-ports/pull/13331

> On Dec 12, 2021, at 7:36 AM, Nils Breunese  wrote:
> 
> 2. elasticsearch 7.15.2_0 includes log4j-core-2.11.1.jar, which is a 
> vulnerable version of Log4J 2.x
> 
> https://github.com/elastic/elasticsearch/issues/81618 
>  says: "This can be 
> mitigated for the time being by adding -Dlog4j2.formatMsgNoLookups=true to 
> ES_JAVA_OPTS". I think I’d add -Dlog4j2.formatMsgNoLookups=true in 
> /opt/local/etc/elasticsearch/jvm.options, or add ES_JAVA_OPTS="$ES_JAVA_OPTS 
> -Dlog4j2.formatMsgNoLookups=true" at the end of 
> /opt/local/bin/elasticsearch-env.



smime.p7s
Description: S/MIME cryptographic signature

Re: Significant security vulnerability discovered in Log4j

[Eric Gallager via macports-dev]

On Sun, Dec 12, 2021 at 3:53 PM Nils Breunese  wrote:
>
> Nils Breunese  wrote:
>
> > Eric Gallager  wrote:
> >
> >> On Sun, Dec 12, 2021 at 4:57 AM Joshua Root  wrote:
> >>>
> >>> On 2021-12-12 20:02 , Nils Breunese wrote:
>  It could be the case the MacPorts has ports for Java-based applications 
>  that include a vulnerable version of the Log4J library. A port that 
>  includes a file called log4j-$version.jar with $version in the range 
>  2.0.0-2.14.1 could be vulnerable. This file could also be ‘hidden’ 
>  inside a compressed archive, like a .war file (basically a zip file). 
>  I’m not sure how we could check all ports for this without installing 
>  all of them.
> >>>
> >>> Not all ports have installed file information available, but the web app
> >>> can search the ones that do:
> >>>
> >>> 
> >>>
> >>> - Josh
> >>
> >> Some other ports with log4j-related files that don't show up in this
> >> search: spring-framework25 +with_libs (from the 1.x series, so it's
> >> safe), slf4j (just docs, so it's safe), log4jdbc (also old, and
> >> possibly a spurious string match, so probably also safe), duck (1.x
> >> series, so it's safe), apache-ant (not seeing version info, I dunno),
> >> apache-geode (this one might actually need checking?),
> >> appengine-java-sdk (not sure), ghidra (this one looks vulnerable), poi
> >> (1.x series, so it's safe), webtoolkit-java-sdk (I dunno), zanata-cli
> >> (1.x series, so it's safe), and commons-logging (doesn't even build).
> >> I'll attach the output of `locate /opt/local/*log4j* | xargs port
> >> provides` to this email so you can see the same list I was looking at.
> >> 
> >
> > I said to look log4j-$version.jar earlier, but I should have said 
> > log4j-core-$version.jar.
> >
> > In your list apache-solr8 and apache-geode contain vulnerable versions of 
> > Log4J 2.x.
>
> And ghidra indeed, sorry.
>
> The version of Apache Geode in MacPorts (1.0.0-incubating) is also rather 
> old. Version 1.14.1 of Apache Geode bumped its dependency on Log4J to 2.15.0, 
> which is the fixed version: 
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.1
>
> Nils.

There's bug 58631 open for an update to apache-geode:
https://trac.macports.org/ticket/58631
And I opened bug 64199 for ghidra: https://trac.macports.org/ticket/64199

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Nils Breunese  wrote:

> Eric Gallager  wrote:
> 
>> On Sun, Dec 12, 2021 at 4:57 AM Joshua Root  wrote:
>>> 
>>> On 2021-12-12 20:02 , Nils Breunese wrote:
 It could be the case the MacPorts has ports for Java-based applications 
 that include a vulnerable version of the Log4J library. A port that 
 includes a file called log4j-$version.jar with $version in the range 
 2.0.0-2.14.1 could be vulnerable. This file could also be ‘hidden’ inside 
 a compressed archive, like a .war file (basically a zip file). I’m not 
 sure how we could check all ports for this without installing all of them.
>>> 
>>> Not all ports have installed file information available, but the web app
>>> can search the ones that do:
>>> 
>>> 
>>> 
>>> - Josh
>> 
>> Some other ports with log4j-related files that don't show up in this
>> search: spring-framework25 +with_libs (from the 1.x series, so it's
>> safe), slf4j (just docs, so it's safe), log4jdbc (also old, and
>> possibly a spurious string match, so probably also safe), duck (1.x
>> series, so it's safe), apache-ant (not seeing version info, I dunno),
>> apache-geode (this one might actually need checking?),
>> appengine-java-sdk (not sure), ghidra (this one looks vulnerable), poi
>> (1.x series, so it's safe), webtoolkit-java-sdk (I dunno), zanata-cli
>> (1.x series, so it's safe), and commons-logging (doesn't even build).
>> I'll attach the output of `locate /opt/local/*log4j* | xargs port
>> provides` to this email so you can see the same list I was looking at.
>> 
> 
> I said to look log4j-$version.jar earlier, but I should have said 
> log4j-core-$version.jar.
> 
> In your list apache-solr8 and apache-geode contain vulnerable versions of 
> Log4J 2.x.

And ghidra indeed, sorry.

The version of Apache Geode in MacPorts (1.0.0-incubating) is also rather old. 
Version 1.14.1 of Apache Geode bumped its dependency on Log4J to 2.15.0, which 
is the fixed version: 
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.1

Nils.

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Eric Gallager  wrote:

> On Sun, Dec 12, 2021 at 4:57 AM Joshua Root  wrote:
>> 
>> On 2021-12-12 20:02 , Nils Breunese wrote:
>>> It could be the case the MacPorts has ports for Java-based applications 
>>> that include a vulnerable version of the Log4J library. A port that 
>>> includes a file called log4j-$version.jar with $version in the range 
>>> 2.0.0-2.14.1 could be vulnerable. This file could also be ‘hidden’ inside a 
>>> compressed archive, like a .war file (basically a zip file). I’m not sure 
>>> how we could check all ports for this without installing all of them.
>> 
>> Not all ports have installed file information available, but the web app
>> can search the ones that do:
>> 
>> 
>> 
>> - Josh
> 
> Some other ports with log4j-related files that don't show up in this
> search: spring-framework25 +with_libs (from the 1.x series, so it's
> safe), slf4j (just docs, so it's safe), log4jdbc (also old, and
> possibly a spurious string match, so probably also safe), duck (1.x
> series, so it's safe), apache-ant (not seeing version info, I dunno),
> apache-geode (this one might actually need checking?),
> appengine-java-sdk (not sure), ghidra (this one looks vulnerable), poi
> (1.x series, so it's safe), webtoolkit-java-sdk (I dunno), zanata-cli
> (1.x series, so it's safe), and commons-logging (doesn't even build).
> I'll attach the output of `locate /opt/local/*log4j* | xargs port
> provides` to this email so you can see the same list I was looking at.
> 

I said to look log4j-$version.jar earlier, but I should have said 
log4j-core-$version.jar.

In your list apache-solr8 and apache-geode contain vulnerable versions of Log4J 
2.x.

Nils.

Re: Significant security vulnerability discovered in Log4j

[Steven Smith]

Please see: https://github.com/macports/macports-ports/pull/13322

> On Dec 12, 2021, at 7:36 AM, Nils Breunese  wrote:
> 
> https://github.com/apache/solr/pull/454#issuecomment-991066278 
>  says: "Just 
> open your solr.in.sh in your favorite editor and add SOLR_OPTS="$SOLR_OPTS 
> -Dlog4j2.formatMsgNoLookups=true". Restart Solr. Done, all safe.”



smime.p7s
Description: S/MIME cryptographic signature

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Nils Breunese  wrote:

> For versions of Log4J 2.x older than these properties are not read yet. (…)

I meant to write: For versions of Log4J 2.x older than *2.10* these properties 
are not read yet, so you can’t use the properties to mitigate the vulnerability 
if you’re using Log4J < 2.10.

Nils.

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Joshua Root  wrote:

> On 2021-12-12 20:02 , Nils Breunese wrote:
>> It could be the case the MacPorts has ports for Java-based applications that 
>> include a vulnerable version of the Log4J library. A port that includes a 
>> file called log4j-$version.jar with $version in the range 2.0.0-2.14.1 could 
>> be vulnerable. This file could also be ‘hidden’ inside a compressed archive, 
>> like a .war file (basically a zip file). I’m not sure how we could check all 
>> ports for this without installing all of them.
> 
> Not all ports have installed file information available, but the web app can 
> search the ones that do:
> 
> 

I’ve locally installed those five ports and found two ports that come with 
vulnerable versions of Log4J 2.x:

1. apache-solr8 8.9.0_0 includes log4j-core-2.13.2.jar, which is a vulnerable 
version of Log4J 2.x

https://github.com/apache/solr/pull/454#issuecomment-991066278 says: "Just open 
your solr.in.sh in your favorite editor and add SOLR_OPTS="$SOLR_OPTS 
-Dlog4j2.formatMsgNoLookups=true". Restart Solr. Done, all safe.”

This could be added in /opt/local/share/java/solr-8.9.0/bin/solr.in.sh.

2. elasticsearch 7.15.2_0 includes log4j-core-2.11.1.jar, which is a vulnerable 
version of Log4J 2.x

https://github.com/elastic/elasticsearch/issues/81618 says: "This can be 
mitigated for the time being by adding -Dlog4j2.formatMsgNoLookups=true to 
ES_JAVA_OPTS". I think I’d add -Dlog4j2.formatMsgNoLookups=true in 
/opt/local/etc/elasticsearch/jvm.options, or add ES_JAVA_OPTS="$ES_JAVA_OPTS 
-Dlog4j2.formatMsgNoLookups=true" at the end of 
/opt/local/bin/elasticsearch-env.

The other three ports (gradle, mvnd, NetBeans) do not include Log4J 2.x.

The vulnerability can generally be mitigated by setting the system property 
log4j2.formatMsgNoLookups to true (e.g. by passing 
-Dlog4j2.formatMsgNoLookups=true to a java startup command), or by setting the 
LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.

For versions of Log4J 2.x older than these properties are not read yet. In that 
case you might want to delete the JndiLookup class from the log4j-core file:

zip -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class

Nils.

Re: Significant security vulnerability discovered in Log4j

[Joshua Root]

On 2021-12-12 20:02 , Nils Breunese wrote:

It could be the case the MacPorts has ports for Java-based applications that 
include a vulnerable version of the Log4J library. A port that includes a file 
called log4j-$version.jar with $version in the range 2.0.0-2.14.1 could be 
vulnerable. This file could also be ‘hidden’ inside a compressed archive, like 
a .war file (basically a zip file). I’m not sure how we could check all ports 
for this without installing all of them.


Not all ports have installed file information available, but the web app 
can search the ones that do:




- Josh

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Eric Gallager wrote:

> On Fri, Dec 10, 2021 at 6:00 PM Jason Liu  wrote:
>> 
>> In case everyone hadn't heard the news. If anyone is running Log4j for 
>> logging on any of your web servers, you might want to read this.
>> 
>> WIRED: 'The Internet Is On Fire'
>> A vulnerability in the Log4j logging framework has security teams scrambling 
>> to put in a fix.
>> 
>> --
>> Jason Liu
> 
> so... is there anything to do about this in MacPorts?
> 
> $ port search log4j
> jakarta-log4j @1.2.16 (java, devel)
>Java logging API
> 
> log4cxx @0.10.0_1 (devel)
>log4cxx is a port to C++ of the log4j project
> 
> log4jdbc @1.1 (java)
>JDBC driver that can log SQL and/or JDBC calls
> 
> p5-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> p5.28-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5.28-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> p5.30-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5.30-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> p5.32-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5.32-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> Found 11 ports.
> $ port installed `port -q search log4j`
> The following ports are currently installed:
>  jakarta-log4j @1.2.16_0 (active)
>  log4jdbc @1.1_0 (active)
>  p5.28-log-log4perl @1.540.0_0 (active)
>  p5.30-log-log4perl @1.540.0_0 (active)
>  p5.32-log-log4perl @1.540.0_0 (active)
> $
> 
> ...I don't think any of these are the same thing, are they?

I’m a Java developer and MacPorts OpenJDK maintainer and to me none of these 
ports look related to Log4J 2.x, which is the vulnerable library.

It could be the case the MacPorts has ports for Java-based applications that 
include a vulnerable version of the Log4J library. A port that includes a file 
called log4j-$version.jar with $version in the range 2.0.0-2.14.1 could be 
vulnerable. This file could also be ‘hidden’ inside a compressed archive, like 
a .war file (basically a zip file). I’m not sure how we could check all ports 
for this without installing all of them.

Nils.

Re: Significant security vulnerability discovered in Log4j

[Jason Liu]

On Sat, Dec 11, 2021 at 1:32 PM Eric Gallager  wrote:

>
> so... is there anything to do about this in MacPorts?
>

There's probably nothing that can be done in terms of the MacPorts
packages. It's basically dependent on upstream developers to patch anything
that might be affected. It was more of a general warning to anyone on the
mailing list that might be running a web server.

...I don't think any of these are the same thing, are they?
>

Based on my googling, jakarta-log4j is some sort of wrapper that allows
Jakarta to use log4j, so it's quite possible that the jakarta-log4j package
is affected. Depending on how closely the C++ port follows the original
Java in the log4cxx package, it might also be affected; the same applies to
the log4perl packages.

-- 
Jason Liu


On Sat, Dec 11, 2021 at 1:32 PM Eric Gallager  wrote:

> On Fri, Dec 10, 2021 at 6:00 PM Jason Liu  wrote:
> >
> > In case everyone hadn't heard the news. If anyone is running Log4j for
> logging on any of your web servers, you might want to read this.
> >
> > WIRED: 'The Internet Is On Fire'
> > A vulnerability in the Log4j logging framework has security teams
> scrambling to put in a fix.
> >
> > --
> > Jason Liu
>
> so... is there anything to do about this in MacPorts?
>
> $ port search log4j
> jakarta-log4j @1.2.16 (java, devel)
> Java logging API
>
> log4cxx @0.10.0_1 (devel)
> log4cxx is a port to C++ of the log4j project
>
> log4jdbc @1.1 (java)
> JDBC driver that can log SQL and/or JDBC calls
>
> p5-log-dispatch-config @1.40.0 (perl)
> Log::Dispatch::Config - Log4j for Perl
>
> p5-log-log4perl @1.540.0 (perl)
> Log4j implementation for Perl
>
> p5.28-log-dispatch-config @1.40.0 (perl)
> Log::Dispatch::Config - Log4j for Perl
>
> p5.28-log-log4perl @1.540.0 (perl)
> Log4j implementation for Perl
>
> p5.30-log-dispatch-config @1.40.0 (perl)
> Log::Dispatch::Config - Log4j for Perl
>
> p5.30-log-log4perl @1.540.0 (perl)
> Log4j implementation for Perl
>
> p5.32-log-dispatch-config @1.40.0 (perl)
> Log::Dispatch::Config - Log4j for Perl
>
> p5.32-log-log4perl @1.540.0 (perl)
> Log4j implementation for Perl
>
> Found 11 ports.
> $ port installed `port -q search log4j`
> The following ports are currently installed:
>   jakarta-log4j @1.2.16_0 (active)
>   log4jdbc @1.1_0 (active)
>   p5.28-log-log4perl @1.540.0_0 (active)
>   p5.30-log-log4perl @1.540.0_0 (active)
>   p5.32-log-log4perl @1.540.0_0 (active)
> $
>
> ...I don't think any of these are the same thing, are they?
>

Re: Significant security vulnerability discovered in Log4j

[Eric Gallager via macports-dev]

On Fri, Dec 10, 2021 at 6:00 PM Jason Liu  wrote:
>
> In case everyone hadn't heard the news. If anyone is running Log4j for 
> logging on any of your web servers, you might want to read this.
>
> WIRED: 'The Internet Is On Fire'
> A vulnerability in the Log4j logging framework has security teams scrambling 
> to put in a fix.
>
> --
> Jason Liu

so... is there anything to do about this in MacPorts?

$ port search log4j
jakarta-log4j @1.2.16 (java, devel)
Java logging API

log4cxx @0.10.0_1 (devel)
log4cxx is a port to C++ of the log4j project

log4jdbc @1.1 (java)
JDBC driver that can log SQL and/or JDBC calls

p5-log-dispatch-config @1.40.0 (perl)
Log::Dispatch::Config - Log4j for Perl

p5-log-log4perl @1.540.0 (perl)
Log4j implementation for Perl

p5.28-log-dispatch-config @1.40.0 (perl)
Log::Dispatch::Config - Log4j for Perl

p5.28-log-log4perl @1.540.0 (perl)
Log4j implementation for Perl

p5.30-log-dispatch-config @1.40.0 (perl)
Log::Dispatch::Config - Log4j for Perl

p5.30-log-log4perl @1.540.0 (perl)
Log4j implementation for Perl

p5.32-log-dispatch-config @1.40.0 (perl)
Log::Dispatch::Config - Log4j for Perl

p5.32-log-log4perl @1.540.0 (perl)
Log4j implementation for Perl

Found 11 ports.
$ port installed `port -q search log4j`
The following ports are currently installed:
  jakarta-log4j @1.2.16_0 (active)
  log4jdbc @1.1_0 (active)
  p5.28-log-log4perl @1.540.0_0 (active)
  p5.30-log-log4perl @1.540.0_0 (active)
  p5.32-log-log4perl @1.540.0_0 (active)
$

...I don't think any of these are the same thing, are they?

Significant security vulnerability discovered in Log4j

[Jason Liu]

In case everyone hadn't heard the news. If anyone is running Log4j for
logging on any of your web servers, you might want to read this.

WIRED: 'The Internet Is On Fire'

A vulnerability in the Log4j logging framework has security teams
scrambling to put in a fix.

-- 
Jason Liu