Rocket MVS Toolkit v2.3.2 Released!

Version 2.3.2 of the Rocket MVS Toolkit RESTful services tool for D3 and mvBase was released this afternoon. Installers and documentation can be found on the Rocket Community Portal:

https://my.rocketsoftware.com/RocketCommunity#/downloads

With this new version of the MVS Toolkit, MVSTK logging was upgraded to log4j 2.17.2 to address security vulnerabilities. Also, OpenJDK was upgraded to OpenJDK 11 to support TLS 1.3.

------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------

Are you saying that the log4j version is 2.17? There was a major problem with log4j 2.17 that was fixed on 12-27-2021 with release 2.17.1. Without that fix, you can still remote execute within the code.
I know this well. I had over 10 attempts on our Universe webserver with bad actors trying to break in before patching it three times with successive releases at 2.15, 2.16, and 2.17 all in December. I installed 2.17.1 at the end of December.
You should upgrade that software quickly.

------------------------------
Doug Averch
Owner
U2 Logic
------------------------------

Hey, Doug, thanks to your post I was able to dive in and find that the actual log4j version in the 2.3.2 Toolkit is 2.17.2. I've changed the appropriate documents ( as well as my original Forum post ) and re-posted with the better version information. Thank you very much!!

------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------

At link below

https://community.rocketsoftware.com/forums/forum-home/digestviewer/viewthread?MessageKey=baf70f35-c774-4a6d-a55d-798598155901&CommunityKey=7cdcd1ff-6009-4df2-8b8c-e5ea4293200b&bm=baf70f35-c774-4a6d-a55d-798598155901#bmbaf70f35-c774-4a6d-a55d-798598155901

I read

NOT IMPACTED:

The following MV products DO NOT contain any version of Log4j, OR contain a version of Log4j that is not impacted by the vulnerability:

MVS Toolkit (among others)

As I can see the Jetty in MVS Tookit is: Jetty(9.3.22.v20171030).. from

https://www.eclipse.org/jetty/documentation/jetty-9/index.html

9.3 is deprecated starting december 2020.

I hoped to see TLS 1.3 support joned to a younger version of Jetty.

Some few customers, sometime, are interested in our products (D3, MVS Toolkiit, ...) and they want to know more about features and so on:security is one of the favourite topics...

Thank You all.
Stefano

------------------------------
Stefano Maran
Senior programmer
GTN SpA
Tavagnacco IT
------------------------------

At link below

https://community.rocketsoftware.com/forums/forum-home/digestviewer/viewthread?MessageKey=baf70f35-c774-4a6d-a55d-798598155901&CommunityKey=7cdcd1ff-6009-4df2-8b8c-e5ea4293200b&bm=baf70f35-c774-4a6d-a55d-798598155901#bmbaf70f35-c774-4a6d-a55d-798598155901

I read

NOT IMPACTED:

The following MV products DO NOT contain any version of Log4j, OR contain a version of Log4j that is not impacted by the vulnerability:

MVS Toolkit (among others)

As I can see the Jetty in MVS Tookit is: Jetty(9.3.22.v20171030).. from

https://www.eclipse.org/jetty/documentation/jetty-9/index.html

9.3 is deprecated starting december 2020.

I hoped to see TLS 1.3 support joned to a younger version of Jetty.

Some few customers, sometime, are interested in our products (D3, MVS Toolkiit, ...) and they want to know more about features and so on:security is one of the favourite topics...

Thank You all.
Stefano

------------------------------
Stefano Maran
Senior programmer
GTN SpA
Tavagnacco IT
------------------------------

Thanks for the post!

Maybe someone could explain the major security discrepancy.

Craig

Craig:

I pulled the below from a Toolkit v2.2.3 case explaining all of this. Please let me know if it helps:

Statement from Engineering re log4j and the MVS Toolkit:

The statement from NIST is:
"Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). 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"."

There are 2 reasons that the MvToolkit is not susceptible to this vulnerability:
The MvToolkit does not utilitize any JNDI (Java Naming and Directory Interface) (including LDAP) endpoint lookups. All of the logging messages are static messages without any dynamic parameters. So regardless of whether the message lookup substitution is enabled or not, there are no messages that require this type of lookup.
The version of Log4j that is delivered with MvToolkit is 1.3 which does not contain the ability to do message lookup substitution and therefore is not susceptible to this vulnerability. That functionality was added to Log4j in version 2.10.

Further MVS Toolkit Vulnerability Inquiry and Engineering's Response:

Question:
As far as I understand you are saying that if the Toolkit does not utilize any JNDI (Java Naming and Directory Interface) (including LDAP) endpoint lookups then it is not susceptible.

However, https://nvd.nist.gov/vuln/detail/CVE-2021-44228 also says it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
I could be wrong, but I think that implies that there is a risk just by JndiLookup class being present, even if it is not being used by the application?
Perhaps the ToolKit does not have the JndiLookup class in the classpath so it already mitigated?

Also, we are typically using older versions of the Toolkit, most commonly 2.2.3.0122 - I am right in saying that this (and all previous versions of the toolkit) will also use a Log4j version < 2.10 and therefore do not have the vulnerability (depending on the answer to the above query)?

Engineering's Response:

Toolkit is not susceptible to this vulnerability because it uses version 1.3 not 2.1 or later. The other statements are also true:
In order for the vulnerability to be exercised the application (mvToolkit in this case) would have to use allow for customizable or parameter-driven log messages. "An attacker who can control log messages or log message parameters can execute arbitrary code" customizable or parameter driven log messages. Since mvToolkit does not have any of these types of log messages there is no way for any attacker to exercise this vulnerability. The statement you are referencing is an alternative way to eliminate the vulnerability if you have the vulnerable code on your system. The JNDI feature was added into log4j 2.0-beta9. So there is no vulnerability with mvToolkit.

General notification from Rocket on this issue released Tuesday December 14th 2021:

Dear Valued Customer,

Customer Security is a top priority for Rocket Software and is an essential part our customer experience. We are constantly improving our capabilities, practices, and our people to deliver products and services that meet the highest security standards.

However, even with this commitment to security excellence, there are still cases where vulnerabilities can be present.

The Rocket Software Security Teams were recently made aware of a vulnerability in the widely utilized Apache Java logging library Log4j2 package that can allow an attacker unauthenticated remote code execution (RCE) access to the servers that the run this software. This vulnerability has been tracked as CVE-2021-44228 and is classified as severe.

With regard to Rocket Software's products, we have identified which software platforms and versions contain the vulnerable Log4j2 utility code and are actively remediating the affected products. Rocket Software highly recommends that customers running impacted software packages follow the Apache recommended mitigation process which can be found here:
https://logging.apache.org/log4j/2.x/security.html

Rocket Software's information security team has implemented preliminary mitigations to protect our enterprise resources against this threat. We continue to evaluate this evolving risk and will deploy additional preventive and detective capabilities within our enterprise technology environment.

Security within our products, services and enterprise is of the upmost importance to Rocket Software. If you have any additional questions or need assistance, please contact Rocket Customer Support (https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport) or ASG Customer Support (https://www.asg.com/en/Support/Access-Login.aspx?func=home).

------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------

Thanks Brian,

Sorry give you extra work in compiling this. It does raise a small concern for me in the future implementation of the toolkit in that it is heavily dependent on other open source projects that can introduce issues. That is the world we live in :(.

Thanks again.

Craig

> On Apr 21, 2022, at 3:03 PM, Brian Cram via Rocket Forum wrote:
>
> Invite your colleagues to join the Rocket Forum and grow our expert network.
>
> D3 and mvBase
> Post New Message Online
> Invite your colleagues to join the Rocket Forum and grow our expert network. Share this link.
> Re: Rocket MVS Toolkit v2.3.2 Released!
> Reply to Group Online Reply to Group
>
> Apr 21, 2022 5:01 PM
> Brian Cram
> Craig:
>
> I pulled the below from a Toolkit v2.2.3 case explaining all of this. Please let me know if it helps:
>
> Statement from Engineering re log4j and the MVS Toolkit:
>
> The statement from NIST is:
> "Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. In previous releases (>2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to "true" or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see www.oracle.com/java/technologies/javase/... protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false"."
>
> There are 2 reasons that the MvToolkit is not susceptible to this vulnerability:
> The MvToolkit does not utilitize any JNDI (Java Naming and Directory Interface) (including LDAP) endpoint lookups. All of the logging messages are static messages without any dynamic parameters. So regardless of whether the message lookup substitution is enabled or not, there are no messages that require this type of lookup.
> The version of Log4j that is delivered with MvToolkit is 1.3 which does not contain the ability to do message lookup substitution and therefore is not susceptible to this vulnerability. That functionality was added to Log4j in version 2.10.
>
> Further MVS Toolkit Vulnerability Inquiry and Engineering's Response:
>
> Question:
> As far as I understand you are saying that if the Toolkit does not utilize any JNDI (Java Naming and Directory Interface) (including LDAP) endpoint lookups then it is not susceptible.
>
> However, nvd.nist.gov/vuln/detail/CVE-2021-44228 also says it can be mitigated in prior releases (<2.10) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
> I could be wrong, but I think that implies that there is a risk just by JndiLookup class being present, even if it is not being used by the application?
> Perhaps the ToolKit does not have the JndiLookup class in the classpath so it already mitigated?
>
> Also, we are typically using older versions of the Toolkit, most commonly 2.2.3.0122 - I am right in saying that this (and all previous versions of the toolkit) will also use a Log4j version < 2.10 and therefore do not have the vulnerability (depending on the answer to the above query)?
>
> Engineering's Response:
>
> Toolkit is not susceptible to this vulnerability because it uses version 1.3 not 2.1 or later. The other statements are also true:
> In order for the vulnerability to be exercised the application (mvToolkit in this case) would have to use allow for customizable or parameter-driven log messages. "An attacker who can control log messages or log message parameters can execute arbitrary code" customizable or parameter driven log messages. Since mvToolkit does not have any of these types of log messages there is no way for any attacker to exercise this vulnerability. The statement you are referencing is an alternative way to eliminate the vulnerability if you have the vulnerable code on your system. The JNDI feature was added into log4j 2.0-beta9. So there is no vulnerability with mvToolkit.
>
> General notification from Rocket on this issue released Tuesday December 14th 2021:
>
> Dear Valued Customer,
>
> Customer Security is a top priority for Rocket Software and is an essential part our customer experience. We are constantly improving our capabilities, practices, and our people to deliver products and services that meet the highest security standards.
>
> However, even with this commitment to security excellence, there are still cases where vulnerabilities can be present.
>
> The Rocket Software Security Teams were recently made aware of a vulnerability in the widely utilized Apache Java logging library Log4j2 package that can allow an attacker unauthenticated remote code execution (RCE) access to the servers that the run this software. This vulnerability has been tracked as CVE-2021-44228 and is classified as severe.
>
> With regard to Rocket Software's products, we have identified which software platforms and versions contain the vulnerable Log4j2 utility code and are actively remediating the affected products. Rocket Software highly recommends that customers running impacted software packages follow the Apache recommended mitigation process which can be found here:
> logging.apache.org/log4j/2.x/security.html
>
> Rocket Software's information security team has implemented preliminary mitigations to protect our enterprise resources against this threat. We continue to evaluate this evolving risk and will deploy additional preventive and detective capabilities within our enterprise technology environment.
>
> Security within our products, services and enterprise is of the upmost importance to Rocket Software. If you have any additional questions or need assistance, please contact Rocket Customer Support (my.rocketsoftware.com/RocketCommunity/RCEmailSupport) or ASG Customer Support (www.asg.com/en/Support/Access-Login.aspx?func=home).
>
> ------------------------------
> Brian S. Cram
> Principal Technical Support Engineer
> Rocket Software
> ------------------------------
> Reply to Group Online View Thread Recommend Forward Flag as Inappropriate Post New Message Online
>

Sign up

Please log in or register:

Welcome to the Rocket Forum!

Please log in or register:

Scanning file for viruses.

This file cannot be downloaded