Java, log4j, log4shell, and OpenVMS: CVE-2021-44228

[Arne Vajhøj]

Java and log4j / log4shell (CVE-2021-44228) remote command execution
vulnerability
intro: https://www.lawfareblog.com/whats-deal-log4shell-security-nightmare
Base OpenVMS itself does not include Java, though add-on apps and
layered products can have dependencies and can install Java.
If you have Java installed anywhere on OpenVMS (try DIRECTORY
ddcu:[*...]JAVA*, etc), you will need to evaluate your configuration in
more detail.
You'll want to evaluate other components and services around your
servers, as well.
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592#file-20211210-tlp-white_log4j-md
Reportedly, all versions of Java are vulnerable when log4i is present
and reachable, and exploits are active and under development.
It appears there are efforts underway to create worms using this
vulnerability, as well.

"all versions of Java are vulnerable when log4j is present and reachable"

is a funny description.

It is a vulnerability for all running Java applications using
log4j 2.0 - 2.14.1 that logs user input.

That is serious. A very large portion of Java server applications
(think 50% magnitude!) use log4j and it seems likely that most of
them have potential for logging user input (user input is important
when troubleshooting).

The version of Java does not impact a bug in log4j more than
the version of C compiler impact a buffer overrun in a C library.

Note that log4j 2.x does not run on VMS Alpha due to too old Java
version (2.0 - 2.3 requires Java 6, 2.4 - 2.12.1 requires Java 7 and
2.13 and newer requires Java 8).

And log4j 1.x is not vulnerable to this bug. But it is out of
support and has other vulnerabilities, so it is not a good
version to be on.

But anybody running a Java application on Itanium that uses
log4j 2.x better upgrade to 2.15 or newer (latest as of today
is 2.16).

To check:

$ dir [whereever...]log4j-core-2.*.jar

should reveal any log4j 2.x present ion that tree.

Every system manager would (hopefully) know whether Java
is installed or not - but very few will know offhand
which applications use log4j, so you better check!!

Arne

[Arne Vajhøj]

Post by Arne Vajhøj
$ dir [whereever...]log4j-core-2.*.jar
should reveal any log4j 2.x present ion that tree.
$ dir [whereever...]log4j-core-2*.jar

just in case it is installed on an ODS-2 disk with _ instead of
period.

Also look out for fatjars which could hide its presence.

Arne

[Dennis Boone]

Post by Arne Vajhøj
(think 50% magnitude!)

Optimists are so cute.

De

[Craig A. Berry]

Post by Arne Vajhøj
The version of Java does not impact a bug in log4j more than
the version of C compiler impact a buffer overrun in a C library.

Not true. From <https://www.openwall.com/lists/oss-security/2021/12/10/1>:

---
Java 8u121 (see
https://www.oracle.com/java/technologies/javase/8u121-relnotes.html)
protects against remote code execution by defaulting
"com.sun.jndi.rmi.object.trustURLCodebase" and
"com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
---

So an up-to-date Java (currently I think 1.8.0_312-b07 for Java 8)
mitigates (some of) the mayhem that can be caused by the vulnerability.
Unless I missed one, the latest release from VSI is 1.8.0_222-b05, so
people using Java 8 on VMS should consider getting that if they are
using any older release of Java 8, including, IIRC, any release from HPE.

But also note per this:

<https://www.openwall.com/lists/oss-security/2021/12/10/2>

that an updated Java protects against only one of several remote code
execution vectors, so it's far from a complete fix, but the Java version
certainly does impact the severity of the bug.

[Arne Vajhøj]

Post by Craig A. Berry

Post by Arne Vajhøj
The version of Java does not impact a bug in log4j more than
the version of C compiler impact a buffer overrun in a C library.

---
Java 8u121 (see
https://www.oracle.com/java/technologies/javase/8u121-relnotes.html)
protects against remote code execution by defaulting
"com.sun.jndi.rmi.object.trustURLCodebase" and
"com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
---
So an up-to-date Java (currently I think 1.8.0_312-b07 for Java 8)
mitigates (some of) the mayhem that can be caused by the vulnerability.
Unless I missed one, the latest release from VSI is 1.8.0_222-b05, so
people using Java 8 on VMS should consider getting that if they are
using any older release of Java 8, including, IIRC, any release from HPE.
<https://www.openwall.com/lists/oss-security/2021/12/10/2>
that an updated Java protects against only one of several remote code
execution vectors, so it's far from a complete fix, but the Java version
certainly does impact the severity of the bug.

Ah. I stand corrected.

I actually did know that 8u121 did get some of the 9
deserialization protection features backported.

But I did not realize that it would help with this one.

That is good. Most Java 8 users should be way above u121.

Arne

[Arne Vajhøj]

Post by Craig A. Berry
So an up-to-date Java (currently I think 1.8.0_312-b07 for Java 8)
mitigates (some of) the mayhem that can be caused by the
vulnerability. Unless I missed one, the latest release from VSI is
1.8.0_222-b05, so people using Java 8 on VMS should consider getting
that if they are using any older release of Java 8, including, IIRC,
any release from HPE.

Reports that all versions of Java are vulnerable to exploitation when
log4j is accessible.

"accessible"

Why not just say "used".

Early reports that Java 8 and newer were not
vulnerable were later found incorrect.

So you are saying that the deserialization protections done in 9 and
backported to 8u121 are not enough to prevent this vulnerability?

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

 Early reports that Java 8 and newer were not vulnerable were later
found incorrect.

So you are saying that the deserialization protections done in 9 and
backported to 8u121 are not enough to prevent this vulnerability?

Those protections block one of several deserialization mechanisms.  It
helps a little for what I understand to be the easiest way to execute
remote code.  But we're way beyond what's easiest for the state actors
and others who are investing a lot of resources into exploiting this in
the wild.  So do upgrade Java. But don't stop there.

The best obviously is to upgrade log4j.

Nobody needs that feature causing the vulnerability (obviously
except whoever introduced it).

Arne

[Bill Gunshannon]

Post by Arne Vajhøj
The best obviously is to upgrade log4j.
Nobody needs that feature causing the vulnerability (obviously
except whoever introduced it).

I wonder how that feature got past a design review ?

People do design reviews?

I wonder if there were too many layers involved for someone to be
able to connect the dots ?

bill

[Arne Vajhøj]

Post by Arne Vajhøj
The best obviously is to upgrade log4j.
Nobody needs that feature causing the vulnerability (obviously
except whoever introduced it).

I wonder how that feature got past a design review ?

Good question. It should not have.

I wonder if there were too many layers involved for someone to be
able to connect the dots ?

There are some code in loggers, but the architecture is pretty simple:

|--multiple formatters
core--|
|--multiple appenders

Arne

[Jim]

HPE has indicated that 3PAR and some other products are vulnerable to

Seems HPE now reporting that the 3PAR StorServ is not vulnerable.

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00120086en_us

[Arne Vajhøj]

Post by Jim

HPE has indicated that 3PAR and some other products are vulnerable to

Seems HPE now reporting that the 3PAR StorServ is not vulnerable.
https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00120086en_us

You're looking at the "not vulnerable" list from HPE.
You'll also want to review the "vulnerable" list from HPE, for some
problematic 3PAR and XP apps.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=hpesbgn04215en_us

I saw a list for multiple vendors:

https://www.continuitysoftware.com/blog/centralized-list-of-storage-and-backup-systems-affected-by-zero-day-log4shell-vulnerability-cve-2021-44228

It is a pretty long list!

:-(

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Jim

HPE has indicated that 3PAR and some other products are vulnerable to

Seems HPE now reporting that the 3PAR StorServ is not vulnerable.
https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-a00120086en_us

You're looking at the "not vulnerable" list from HPE.
You'll also want to review the "vulnerable" list from HPE, for some
problematic 3PAR and XP apps.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=hpesbgn04215en_us

https://www.continuitysoftware.com/blog/centralized-list-of-storage-and-backup-systems-affected-by-zero-day-log4shell-vulnerability-cve-2021-44228
It is a pretty long list!
:-(

https://www.bleepingcomputer.com/news/security/conti-ransomware-uses-log4j-bug-to-hack-vmware-vcenter-servers

Arne

[Simon Clubley]

HPE has indicated that 3PAR and some other products are vulnerable to
this mess,

Which is a pretty good indication of how big the problem is.
3PAR is not exactly what one assocoate with a Java server.
Some security guy was out in the medias today and say that they expect
it to take 2 years before everyone has patched.

Based on previous major events, that would not surprise me.

Perhaps now we might actually move away from needing to use 5 zillion
layers to be able to write a modern version of a Hello World application...

Simon.

[Bill Gunshannon]

On 12/13/21 8:51 PM, Arne Vajhøj wrote:
...

Post by Arne Vajhøj
The version of Java does not impact a bug in log4j more than
the version of C compiler impact a buffer overrun in a C library.

We keep hearing this mantra over and over. If it really is
such a problem why has no one ever bothered to write a new
library keeping the original APIs while internally removing
the overrun problem? Oh wait, someone did. Back in the early
80's. On the PDP-11. For all the DEC OSes and Ultrix-11
and Version 7 Unix. And there was even a version for the VAX.
How did that work out?

bill

[Bill Gunshannon]

...

Post by Arne Vajhøj
The version of Java does not impact a bug in log4j more than
the version of C compiler impact a buffer overrun in a C library.

We keep hearing this mantra over and over.  If it really is
such a problem why has no one ever bothered to write a new
library keeping the original APIs while internally removing
the overrun problem?  Oh wait, someone did. Back in the early
80's.  On the PDP-11.  For all the DEC OSes and Ultrix-11
and Version 7 Unix.  And there was even a version for the VAX.
How did that work out?
bill

Way too many people don't really care about security ... until it bites
them on the ass.  Then they expect a law to be passed that will protect
them.  As if the hackers really care about laws.
One moment I'll never forget.  I was telling a customer that it would be
a very bad idea for them to store their customer's data, bank account,
credit card info, and such in plain text on a IIS server.  The response
was "why not, everyone else does".  And they ignored my warning and did
just that.  Don't know the result, the business relationship didn't last
much longer.

And then you have the cloud. Take all your data and place it in the
hands of someone you have no reason to trust.

bill

[David Turner]

So the vulnerability is there. How would one take advantage of it anyway?
Wouldn't you need a privileged account to even get into the server to
start taking advantage of the flaws?
Assuming one is pretty careful about access to the network, and the
directory permissions are controlled, wouldn't it be hard to get to do
any damage?

Curious as I cannot find much information outside of the warning. I
guess no one wants to give hackers the keys to the rolls....

DT

Post by Arne Vajhøj
The version of Java does not impact a bug in log4j more than
the version of C compiler impact a buffer overrun in a C library.

We keep hearing this mantra over and over.  If it really is
such a problem why has no one ever bothered to write a new
library keeping the original APIs while internally removing
the overrun problem?  Oh wait, someone did. Back in the early
80's.  On the PDP-11.  For all the DEC OSes and Ultrix-11
and Version 7 Unix.  And there was even a version for the VAX.
How did that work out?
bill

Way too many people don't really care about security ... until it
bites them on the ass.  Then they expect a law to be passed that will
protect them.  As if the hackers really care about laws.
One moment I'll never forget.  I was telling a customer that it would
be a very bad idea for them to store their customer's data, bank
account, credit card info, and such in plain text on a IIS server. 
The response was "why not, everyone else does". And they ignored my
warning and did just that.  Don't know the result, the business
relationship didn't last much longer.

And then you have the cloud.  Take all your data and place it in the
hands of someone you have no reason to trust.
bill

So

[Stephen Hoffman]

Post by David Turner
So the vulnerability is there. How would one take advantage of it anyway?
Wouldn't you need a privileged account to even get into the server to
start taking advantage of the flaws?
Assuming one is pretty careful about access to the network, and the
directory permissions are controlled, wouldn't it be hard to get to do
any damage?
Curious as I cannot find much information outside of the warning. I
guess no one wants to give hackers the keys to the rolls....

It's a full remote command execution flaw (RCE), meaning that pretty
much anything that the Java app has access to is also exposed to the
attacker, if the attacker can get the exploit text string to the
logging software.

Access to the vulnerable logger can be via host name string, by HTTP
headers, or by embedding the text into other data streams, depending on
the app involved. It varies. Widely.

What can you do with the vulnerability? There are reportedly already
cryptocurrency miners and ransomware efforts underway using the
vulnerability, and I expect we'll see a long tail of more...

An intro to the log4j vulnerability from the Swiss government:
https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/


List of affected products (re-post) :
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

One of the security vendors with some info:
https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/

There's a Python detection tool at that last URL, though I've not
checked to see if that might be reasonably portable to OpenVMS.

Been working with some OpenVMS folks on this, and y'all with Java
installed and Java apps in use will want to take a look at what's in
those jars. Or if you have Java installed and don't need it, best
remove it.

[Arne Vajhøj]

Post by David Turner
So the vulnerability is there. How would one take advantage of it anyway?
Wouldn't you need a privileged account to even get into the server to
start taking advantage of the flaws?
Assuming one is pretty careful about access to the network, and the
directory permissions are controlled, wouldn't it be hard to get to do
any damage?
Curious as I cannot find much information outside of the warning. I
guess no one wants to give hackers the keys to the rolls....

The vulnerability is in the processing of log messages in
a logging framework.

To exploit the attackers need to get a specific message
logged.

And that is usually pretty easy. The primary purpose of logging
is to help troubleshooting problems and to do that it makes sense
to log user input.

It does not matter how the user input comes into the system.

The two most common ways are probably:
* web service calls coming in from the internet
* web form post coming in from internet

But it could also be an insider instead of internet.

And it could be plain socket or a message queue or a file
instead of HTTP(S).

Because the problem is in the data content, then traditional
isolation often doesn't help.

--firewall--Java web service with log4j

--firewall--Apache httpd proxy--firewall--Java web service with log4j

--firewall--Apache httdd proxy--firewall--PHP web service--message
queue--Java backend with log4j

--firewall--Apache httdd proxy--firewall--PHP web
service--database--Python job--message queue--Java backend with log4j

does not make a difference if that Java code calls log4j with
user input with malicious content then bad things can happen.

To move on with the exploit the Java code need to be able to
reach a server controlled by the attacker, but many places
only have strict control of inbound traffic not outbound traffic.

And the Java code need to have access to something. But if the
code is intended to do something on behalf of the user then it
obviously need to have access to user data. That it may not have
access to modify OS does not stop bad things from happening.

Arne

[David Turner]

I wonder if there is anything that can be done in the .htaccess file

I have most countries outside of our business realm blocked so they
cannot even connect to the website
Since these attempts are typically made by a few malicious players in a
few countries, blocking access via country and ip has really helped us

Post by Arne Vajhøj

Post by David Turner
So the vulnerability is there. How would one take advantage of it anyway?
Wouldn't you need a privileged account to even get into the server to
start taking advantage of the flaws?
Assuming one is pretty careful about access to the network, and the
directory permissions are controlled, wouldn't it be hard to get to
do any damage?
Curious as I cannot find much information outside of the warning. I
guess no one wants to give hackers the keys to the rolls....

The vulnerability is in the processing of log messages in
a logging framework.
To exploit the attackers need to get a specific message
logged.
And that is usually pretty easy. The primary purpose of logging
is to help troubleshooting problems and to do that it makes sense
to log user input.
It does not matter how the user input comes into the system.
* web service calls coming in from the internet
* web form post coming in from internet
But it could also be an insider instead of internet.
And it could be plain socket or a message queue or a file
instead of HTTP(S).
Because the problem is in the data content, then traditional
isolation often doesn't help.
--firewall--Java web service with log4j
--firewall--Apache httpd proxy--firewall--Java web service with log4j
--firewall--Apache httdd proxy--firewall--PHP web service--message
queue--Java backend with log4j
--firewall--Apache httdd proxy--firewall--PHP web
service--database--Python job--message queue--Java backend with log4j
does not make a difference if that Java code calls log4j with
user input with malicious content then bad things can happen.
To move on with the exploit the Java code need to be able to
reach a server controlled by the attacker, but many places
only have strict control of inbound traffic not outbound traffic.
And the Java code need to have access to something. But if the
code is intended to do something on behalf of the user then it
obviously need to have access to user data. That it may not have
access to modify OS does not stop bad things from happening.
Arne

[Arne Vajhøj]

Post by David Turner
I wonder if there is anything that can be done in the .htaccess file

I don't think so.

It must be possible to come up with blocking rules for mod_security though.

Post by David Turner
I have most countries outside of our business realm blocked so they
cannot even connect to the website
Since these attempts are typically made by a few malicious players in a
few countries, blocking access via country and ip has really helped us

That can help against amateur hackers.

It does not help against the more professional hackers.

This vulnerability is supposedly already being exploited by what
is known as "state actors".

Arne

[Stephen Hoffman]

Post by David Turner
I wonder if there is anything that can be done in the .htaccess file

Any data stream within any Java app that happens to incorporate the
vulnerable logger is a potential vulnerability.

Successfully blocking all of that that access via .htaccess from all
potential sources is roughly equivalent to shutting down the app.

Web application firewalls are failing at similar filtering tasks, given
the variability and ease of masking the JNDI exploit text strings.

[David Turner]

SO if it tends to be "state actors" blocking those "states" or countries
may be the best option to start off.

Post by Stephen Hoffman

Post by David Turner
I wonder if there is anything that can be done in the .htaccess file

Any data stream within any Java app that happens to incorporate the
vulnerable logger is a potential vulnerability.
Successfully blocking all of that that access via .htaccess from all
potential sources is roughly equivalent to shutting down the app.
Web application firewalls are failing at similar filtering tasks,
given the variability and ease of masking the JNDI exploit text strings.

[Arne Vajhøj]

Post by David Turner
SO if it tends to be "state actors" blocking those "states" or countries
may be the best option to start off.

No.

State actors are very professional.

You can be sure that they have network services available so they can
pretend to be from any country they want to.

Arne

[Dennis Boone]

Post by David Turner
SO if it tends to be "state actors" blocking those "states" or countries
may be the best option to start off.

Blocking countries... by IP address? I don't know how else you'd try
to do that. But it's porous as hell. US-EAST-1 is in Virginia, and
Amazon certainly doesn't prevent foreigners from setting up VMs there.
Many VPN options. Etc. Any state actor that can't trivially work
around an IP range block isn't really a state actor.

The best option is to get the vulnerable log4j versions off your
servers. Period. Only hippopotamus will do.

De

[Simon Clubley]

Post by Dennis Boone
Any state actor that can't trivially work
around an IP range block isn't really a state actor.

Well, they could always be working for Grand Fenwick... :-)

Simon.

[Stephen Hoffman]

Post by David Turner
SO if it tends to be "state actors" blocking those "states" or
countries may be the best option to start off.

With pools of servers available for rental in many states, and with
misconfigured and breached computers ~everywhere, that would not be an
entirely reliable strategy.

[Phillip Helbig (undress to reply)]

Post by David Turner
SO if it tends to be "state actors" blocking those "states" or countries
may be the best option to start off.

Why would they operate from within their own countries?

[David Turner]

It's better than nothing
I think a lot of US hosting companies also have blocked suspicious
Russian traffic and will not allow non-US companies to be hosted.

It has certainly helped us.

Post by David Turner
SO if it tends to be "state actors" blocking those "states" or
countries may be the best option to start off.

Not necessarily.  You are assuming that the attacks will come
from addresses in their address blocks and that may not be the
case.
bill

[Craig A. Berry]

Note that log4j 2.16.0 has now been released to fix vulnerabilities
still present in the 2.15.0 released a few days ago, and many of the
mitigations published in the last week are now considered inadequate:

<https://logging.apache.org/log4j/2.x/security.html>

[Arne Vajhøj]

Post by Craig A. Berry
Note that log4j 2.16.0 has now been released to fix vulnerabilities
still present in the 2.15.0 released a few days ago, and many of the
<https://logging.apache.org/log4j/2.x/security.html>

Yes.

But the new one is not in the same category as the first.

<quote>
CVE-2021-45046

CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context
Lookup Pattern vulnerable to a denial of service attack.

Severity: Moderate

Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)

Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.15.0
</quote>

vs

<quote>
CVE-2021-44228

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against
attacker controlled LDAP and other JNDI related endpoints.

Severity: Critical

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.14.1
</quote>

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Craig A. Berry
Note that log4j 2.16.0 has now been released to fix vulnerabilities
still present in the 2.15.0 released a few days ago, and many of the
<https://logging.apache.org/log4j/2.x/security.html>

Yes.
But the new one is not in the same category as the first.
<quote>
CVE-2021-45046
CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context
Lookup Pattern vulnerable to a denial of service attack.
Severity: Moderate
Base CVSS Score: 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.15.0
</quote>

They have now updated the severity to:

CVE-2021-45046 Remote Code Execution
Severity Critical
Base CVSS Score 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
Versions Affected All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2

...

Severity is now Critical

The original severity of this CVE was rated as Moderate; since this CVE
was published security experts found additional exploits against the
Log4j 2.15.0 release, that could lead to information leaks, RCE (remote
code execution) and LCE (local code execution) attacks.

Base CVSS Score changed from 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)
to 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

The title of this CVE was changed from mentioning Denial of Service
attacks to mentioning Remote Code Execution attacks.

Only Pattern Layouts with a Context Lookup (for example,
$${ctx:loginId}) are vulnerable to this. This page previously
incorrectly mentioned that Thread Context Map pattern (%X, %mdc, or
%MDC) in the layout would also allow this vulnerability.

While Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP
lookups to localhost by default, there are ways to bypass this and users
should not rely on this.

Post by Arne Vajhøj
vs
<quote>
CVE-2021-44228
CVE-2021-44228: Apache Log4j2 JNDI features do not protect against
attacker controlled LDAP and other JNDI related endpoints.
Severity: Critical
Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0
through 2.14.1
</quote>

Arne

[Simon Clubley]

(Hoff already mentioned that one)

I missed that. Sorry. :-)

Simon.

[Arne Vajhøj]

Post by Simon Clubley

(Hoff already mentioned that one)

I missed that. Sorry. :-)

And they found yet another vulnerability so now 2.17.1 is out.

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley

(Hoff already mentioned that one)

I missed that. Sorry. :-)

And they found yet another vulnerability so now 2.17.1 is out.

On the plus side, at least the discoveries are getting further apart. :-)

As a gentle reminder to everyone, this is what awaits VMS if the
researchers turn their attention to it. Log4j was in use for years
and only after researchers turned their attention to it, did these
longstanding issues get discovered.

I'm sure that when the vulnerable Log4j versions were introduced,
everyone continued to use it without thinking that they may have
just introduced a vulnerability into their application.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley

(Hoff already mentioned that one)

I missed that. Sorry. :-)

And they found yet another vulnerability so now 2.17.1 is out.

On the plus side, at least the discoveries are getting further apart. :-)
As a gentle reminder to everyone, this is what awaits VMS if the
researchers turn their attention to it. Log4j was in use for years
and only after researchers turned their attention to it, did these
longstanding issues get discovered.

It is clear that when some software get a lot of attention then
problems tend to be found.

VMS is not quite as attractive as log4j though.

Post by Simon Clubley
I'm sure that when the vulnerable Log4j versions were introduced,
everyone continued to use it without thinking that they may have
just introduced a vulnerability into their application.

I believe it has been there since 2.0.

2.x API is different from 1.x API, but 2.x comes with a bridge
that supports 1.x API so maybe old applications that were upgraded
from 1.x to 2.x using the bridge is also impacted.

Obviously people were unaware of the problems.

And the vast majority (like 99.99%) have never used the features
that are causing the problems.

Arne

[George Cornelius]

Post by David Turner
It's better than nothing

If it gives you some peace of mind you can try it in the short term.

BTW, some email environments do allow blocking by country of origin,
e.g., Cisco Email Security Appliances. It's something we have chosen
not to use.

But when waiting for a patch to arrive sometimes you grasp at straws.

My home Linux box has Libre Office, and some report writer functionality
had a dependency on log4j and it did not seem to be possible to remove
log4j without using some kind of --force-remove option, although I
suppose I could have just hidden the executable for that portion of
Libre Office.

I see I have the log4j patch in now as part of a routine patch
application, but I don't believe it was there to begin with so I was
exposed for a few days.

George

Post by David Turner
I think a lot of US hosting companies also have blocked suspicious
Russian traffic and will not allow non-US companies to be hosted.
It has certainly helped us.

[Arne Vajhøj]

Post by George Cornelius
My home Linux box has Libre Office, and some report writer functionality
had a dependency on log4j and it did not seem to be possible to remove
log4j without using some kind of --force-remove option, although I
suppose I could have just hidden the executable for that portion of
Libre Office.
I see I have the log4j patch in now as part of a routine patch
application, but I don't believe it was there to begin with so I was
exposed for a few days.

log4j is almost everywhere.

But the attack vector in LO must be rather narrow compared to
all the server applications.

Arne

[John Reagan]

Post by Arne Vajhøj

Post by George Cornelius
My home Linux box has Libre Office, and some report writer functionality
had a dependency on log4j and it did not seem to be possible to remove
log4j without using some kind of --force-remove option, although I
suppose I could have just hidden the executable for that portion of
Libre Office.
I see I have the log4j patch in now as part of a routine patch
application, but I don't believe it was there to begin with so I was
exposed for a few days.

log4j is almost everywhere.
But the attack vector in LO must be rather narrow compared to
all the server applications.
Arne

The trouble is that log4j is at such a low level, it is buried in packages that are
buried in other packages that are buried in even more packages. It might take a
while for all of that to be squeezed out.

[Arne Vajhøj]

Post by John Reagan
The trouble is that log4j is at such a low level, it is buried in packages that are
buried in other packages that are buried in even more packages. It might take a
while for all of that to be squeezed out.

Yep.

A large portion of impacted users do not know that they are using log4j.

Heck - some of them may not even know they are using Java.

Arne

[Grant Taylor]

Post by John Reagan
The trouble is that log4j is at such a low level, it is buried in
packages that are buried in other packages that are buried in even more
packages. It might take a while for all of that to be squeezed out.

Purportedly Google's Project Zero put out a report (though I'm having
trouble finding it) wherein they did a massive analysis of Java packages
and found that Log4j was included as a dependency up to eight levels of
nesting.

Steve Gibson talked about it extensively on Security Now 850 from
December 21st 2021.

You can find a histogram in the show notes for SN 850 on file page 12
numbered page 11:

Link - Security Now 850 Show Notes
- https://www.grc.com/sn/sn-850-notes.pdf

[Arne Vajhøj]

Post by Grant Taylor

Post by John Reagan
The trouble is that log4j is at such a low level, it is buried in
packages that are buried in other packages that are buried in even
more packages.  It might take a while for all of that to be squeezed out.

Purportedly Google's Project Zero put out a report (though I'm having
trouble finding it) wherein they did a massive analysis of Java packages
and found that Log4j was included as a dependency up to eight levels of
nesting.
Steve Gibson talked about it extensively on Security Now 850 from
December 21st 2021.
You can find a histogram in the show notes for SN 850 on file page 12
Link - Security Now 850 Show Notes
 - https://www.grc.com/sn/sn-850-notes.pdf

Yes.

That is the curse of modern package managers. You include
a handful of things and that causes dozens/hundreds/thousands
of dependencies and dependencies of dependencies and ...
to be pulled in.

Java got maven, .NET got NuGet, PHP got composer, Python
got pip, JS got npm and so on (there are many other but the
above should illustrate).

Arne

[John Reagan]

Post by Grant Taylor

Post by John Reagan
The trouble is that log4j is at such a low level, it is buried in
packages that are buried in other packages that are buried in even more
packages. It might take a while for all of that to be squeezed out.

Purportedly Google's Project Zero put out a report (though I'm having
trouble finding it) wherein they did a massive analysis of Java packages
and found that Log4j was included as a dependency up to eight levels of
nesting.
Steve Gibson talked about it extensively on Security Now 850 from
December 21st 2021.
You can find a histogram in the show notes for SN 850 on file page 12
Link - Security Now 850 Show Notes
- https://www.grc.com/sn/sn-850-notes.pdf
--
Grant. . . .
unix || die

Yes, that's where I got my info. I listen to SN (and other podcasts) while I'm working.
I often find myself talking back to Steve/Leo without realizing it (I need real friends, eh?)

[Phillip Helbig (undress to reply)]

Post by Arne Vajhøj

Post by John Reagan
The trouble is that log4j is at such a low level, it is buried in packages that are
buried in other packages that are buried in even more packages. It might take a
while for all of that to be squeezed out.

Yep.
A large portion of impacted users do not know that they are using log4j.
Heck - some of them may not even know they are using Java.

Some might not even know that they are using a computer. :-)

[Arne Vajhøj]

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj

Post by John Reagan
The trouble is that log4j is at such a low level, it is buried in packages that are
buried in other packages that are buried in even more packages. It might take a
while for all of that to be squeezed out.

Yep.
A large portion of impacted users do not know that they are using log4j.
Heck - some of them may not even know they are using Java.

Some might not even know that they are using a computer. :-)

For the cases I was thinking about - storage systems running some
management software - then they would know they were using a computer.

Arne

[Steven Schweda]

I see that my Web server log has started to collect a variety of
"${jndi:ldap:" stuff, some of which is encoded to avoid simple
recognition ("${${lower:j}${lower:n}${lower:d}i:"). Interesting that
because the vulnerability is in the logging, the payload can appear in
the referrer string, not necessarily in the request URL itself. What a
world, what a world...