log4j Vulnerability

Cringer

ProgressTalk.com Moderator
Staff member
Following is a newsletter from White Star Software, Consultingwerk and Riverside Software:

You may have heard that there is a critical security vulnerability in the “log4j” Java library that is used by many applications in the Java ecosystem and you might be wondering if this impacts your OpenEdge environment.

Progress Software has released this K-Base article over the weekend https://knowledgebase.progress.com/articles/Article/Is-OpenEdge-vulnerable-to-CVE-2021-44228-Log4 and provides more information on the page https://www.progress.com/security.

If you are using any of the products mentioned in those articles, we strongly recommend taking immediate action.

Please note, that in the current version of the K-Base article, the JVM Startup parameter is incorrect. We’ve already reached out to Progress Software support to address this issue. The article mentions to set the parameter with a colon between parameter name and value. The correct syntax to set the startup parameter is however: -Dlog4j2.formatMsgNoLookups=true.

Please note, that when copy-and-pasting the parameter from this email or the K-Base article your client may be replacing the hyphen/dash/minus with a long hyphen which will cause errors at runtime.

According to the K-Base article from Progress Software, customers of the SmartComponent Library that are using the classic AppServer and REST Adapter are impacted by the vulnerability.

Customers using PASOE in either OpenEdge 11.7 or OpenEdge 12.x seem to be on the safe side. We have no information about earlier versions of PASOE or OpenEdge in general.

The SmartComponent Library does not use log4j for any of its tooling or other purposes itself.

None the less we encourage everyone to carefully review their Java infrastructure. Many add on components may have incorporated log4j and the vulnerability is being actively exploited. If you have internet facing infrastructure you should act immediately to mitigate the use of log4j by either upgrading to the patched release or by taking the temporary steps described in the articles below.

For more detailed information the following resources are a good start:

https://www.lunasec.io/docs/blog/log4j-zero-day/
https://community.sonarsource.com/t/sonarqube-and-the-log4j-vulnerability/54721
https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
https://thehackernews.com/2021/12/extremely-critical-log4j-vulnerability.html

Auf Deutsch (in German)

https://www.heise.de/news/Roter-Alarm-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen-6292863.html
https://www.spiegel.de/netzwelt/web/bundesbehoerde-warnt-vor-schwachstelle-in-weit-verbreiteter-software-a-55bc413b-2e01-446c-8ee6-5fabfee3b0f2

The content of this Email is provided by Consultingwerk, Riverside and White Star Software.

 

TomBascom

Curmudgeon
Small update... 11.7.11 (the "latest and greatest" 11.7 at this writing) updated log4j to a vulnerable release. So if you are running 11.7.11 and you use the classic REST adapter or the import-export utility or the command center you are exposed and should follow the mitigation instructions.

I haven't heard any promises but 11.7.12 is due out pretty soon and I would guess that will very likely address the issue as well.
 

Robert Anson

New Member
Hi I have downloaded 11.7.12 but I don't see any comment about this Log4j being fixed.
Am I correct in assuming it has not been fixed and therefore to execute this zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ?
 

TomBascom

Curmudgeon
I have not seen any clear communication from Progress specifically regarding 11.7.12 so I would assume that it is vulnerable and follow the suggested mitigations.
 
Top