CVE-2021-44228 Log4j 2 Vulnerability

[Benito Gonzalez]

Hi folks, 
 

You may have heard about the 0-Day Log4j Exploit:

https://logging.apache.org/log4j/2.x/security.html#Fixed_in_Log4j_2.15.0
https://www.lunasec.io/docs/blog/log4j-zero-day/ 
 
uPortal projects have generally moved away from Log4j and on to SLF4J/Logback, even leveraging it as a proxy for Log4j calls (See Resource Server).  Those portlet projects that still use Log4j are using an older version that is not susceptible to this attack.  
 
For CAS, we package an older, customized version for use in Quick Start and dev only. I know of no institution that uses the packaged CAS for their production service. Also, the version of Log4j in this version of CAS is not susceptible to the attack either. 
 
That leaves Resource Server. It does not have Log4j code other than the API. SLF4J is the logging engine. Again, we are safe. 
 

Plus, portlets have limited exposure to direct calls -- most communication is with uPortal. That said, modern portlets are starting to include APIs and other endpoints that are exposed.

Lastly, the vulnerability can be countered by taking the following steps *IF* you find you have custom code that DOES have Log4j2:

1. run Java 8 JDK newer than u191

2. Add `-Dcom.sun.jndi.ldap.object.trustURLCodebase=false` to JAVA_OPTS in Tomcat's setenv.sh/.bat

3. Add `-Dlog4j2.formatMsgNoLookups=true` to JAVA_OPTS in Tomcat's setenv.sh/.bat

4. Upgrade Log4J2 to v2.15.0

In case you need to check Tomcat, this is the Linux command I used to surface Log4j jars:

$ find . -name log4j\*.jar | grep -v slf

./webapps/cas/WEB-INF/lib/log4j-1.2.15.jar

./webapps/esup-filemanager/WEB-INF/lib/log4j-1.2.9.jar

./webapps/BookmarksPortlet/WEB-INF/lib/log4j-1.2.17.jar

./webapps/FunctionalTestsPortlet/WEB-INF/lib/log4j-1.2.16.jar

./webapps/FeedbackPortlet/WEB-INF/lib/log4j-1.2.17.jar

./webapps/resource-server/WEB-INF/lib/log4j-api-2.10.0.jar

./webapps/sakai-connector/WEB-INF/lib/log4j-1.2.16.jar

./webapps/cas-proxy-test-portlet/WEB-INF/lib/log4j-1.2.17.jar

./webapps/basiclti-portlet/WEB-INF/lib/log4j-1.2.16.jar

Have a wonderful day!
-B

--

Benito J. Gonzalez

Software Architect

Unicon, Inc.

209.777.2754

Email:  bgon...@unicon.net

GitHub:  bjagg

GitLab:  bjagg

BitBucket:  bjagg

[Benito Gonzalez]

Hi folks,

If you cannot upgrade your custom code to use the latest Log4j version, here's how to configure your uPortal-start files with the suggested parameters:

https://github.com/uPortal-Project/uPortal-start/pull/553/files

Best,

-B

[Jim Helwig]

Thanks for all your work on this!

--
You received this message because you are subscribed to the Google Groups "uPortal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-dev...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-dev/CAJ_1GkS5SazWNGN9PYxbqj%3DVhtVaZ0bdfRLLnFdire%3D_TNf%3D2Q%40mail.gmail.com.

[Benito Gonzalez]

Oh, someone brought to my attention that only log4j 2 >= 2.10 checks for the `log4j2.formatMsgNoLookups` flag. If you are running a version of Log4j core older than 2.10 you need to upgrade anyway.

Thanks Pascal!

-bjagg

[Benito Gonzalez]

Hey folks,

Here is the latest for you that have custom code that has log4j2 “core” as a dependency. (Again, neither Log4j v1 nor Log4j2 API jars have this vulnerability.)

How to check: search Tomcat webapps/ for “log4j-core-2*.jar”. If found, note the version. This is important.

Latest details on addressing:

- Upgrading Java does not necessarily help, and should not be viewed as a risk mitigation strategy

- Log4j-core 2.x - 2.9 is vulnerable to the RCE, and there is no known workaround. Users should stop using the code and/or upgrade immediately

- Log4j-core 2.10 - 2.14 is vulnerable to the RCE, but can be mitigated by invoking the Java process with -Dlog4j2.formatMsgNoLookups=true , or setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true (would still require an app restart)

- Log4j-core 2.15 (might be earlier as well) has a DOS risk, but the RCE is resolved.

- We recommend upgrading to Log4j 2.16  (core and api) to resolve the RCE and DOS

- This RCE affects noted versions of log4j-core. There is no known RCE risk for log4j-api.

Please reach out to the community if you need assistance! That's what we are here for -- helping each other. If you are a Unicon OSS uPortal subscriber feel free to open a ZenDesk ticket.

Best,

-bjagg