Has anyone else heard about this lo4j 2 vulnerability ...

[Toby Mills]

david.hall:

 

Also TIBCO will be re-issuing the hotfix with logj4 2.16 version shortly. So you may want to hold off on manually doing any copybackupreplace until that is posted

 

 

Very good!

Id like for them to also get up to tomcat 9.55 or higher as the packaged web app server.

The Tomcat users email distribution list sent this out yesterday (for those not subscribed):

 

The following represents the current understanding of the Apache Tomcat security team at the time this announcement was issued. There is a lot of security research being focussed on log4j2 at the moment and it is probable that additional information will emerge.

Currently supported Tomcat versions (8.5.x, 9.0.x, 10.0.x and 10.1.x) have no dependency on any version of log4j.

Web applications deployed on Tomcat may have a dependency on log4j. You should seek support from your application vendors on how best to address this vulnerability.

Tomcat 8.0.x and earlier as well as the first few releases of 8.5.x

(8.5.3 and earlier) provided optional support for switching Tomcats internal logging to log4j 1.x. Anyone one using these very old (5+ years), unsupported versions of Tomcat that switched to using log4j 1.x may need to address this vulnerability as log4j 1.x may be affected in some (probably rarely used) configurations. Regardless, theyll need to address the Tomcat vulnerabilities that have been made public in those

5+ years.

It is possible to configure Tomcat to use log4j 2.x for Tomcats internal logging. This requires explicit configuration and the addition of the log4j 2.x library. Anyone who has switched Tomcats internal logging to log4j 2.x is likely to need to address this vulnerability.

In most cases, disabling the problematic feature will be the simplest solution. Exactly how to do that depends on the exact version of log4j2 being used. Details are provided on the log4j2 security page [1].

If not already subscribed, you may wish to follow the ASF announcements mailing list [2] where any significant updates from the logging project will be posted.

If you have any questions regarding this issue or how to mitigate it, please direct them to the Apache Tomcat Users mailing list [3].

The Apache Tomcat Security Team

[1] https://logging.apache.org/log4j/2.x/security.html

[2] https://www.apache.org/foundation/mailinglists.html#foundation-announce

[3] https://tomcat.apache.org/lists.html#tomcat-users

 

David - its worth noting on the security page (link 1 above) that they also say LOG4J_FORMAT_MSG_NO_LOOKUPS may not be sufficient (but I presume its better than doing nothing):

 

History

Older (discredited) mitigation measures

This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.

The 2.15.0 release was found to still be vulnerable when the configuration has a pattern layout containing a Context Lookup (for example, $${ctx:loginId}), or a Thread Context Map pattern %X, %mdc or %MDC. When an attacker can control Thread Context values, they may inject a JNDI Lookup pattern, which will be evaluated and result in a JNDI connection. Log4j 2.15.0 restricts JNDI connections to localhost by default, but this may still result in DOS (Denial of Service) attacks, or worse.

A new CVE (CVE-2021-45046, see above) was raised for this.

Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.

The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.

The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.

[Warren Hinchliffe]

Perhaps it will be in WF 9.0, expect out in Feb

[Toby Mills]

A colleague just texted to say hes seen something from TIBCO about another fix for this to be rolled out this afternoon.

I cant really confirm that. Anybody else hear anything Ill stop manually patching if an installer version will be available today.

[John Gelona]

Where is the Distribution Server In our environment the Distribution server is on the same machine as the Reporting Server. The client server is on a separate machine. If this describes you, then you have to repeat the ReportCaster steps on the machine where the Distribution Server is located.

I applied the fix in our Test, Dev environments and every thing is fine. I will be doing Prod later today.

[Warren Hinchliffe]

Looks like there is a hot fix for our installation now 8207.28.0. Hit fix 005

The numbering is getting confusing

[Toby Mills]

I see that.

 

It looks like there was also a 8207.28.01 that I didnt do. I dont remember it right off.

Read the readme for your hf005 and it looks like the manual variety of updates.

Ill be doing 4 more of my VMs today to first update to 8207.28.05, then to apply the hotfix for log4j.

Getting a lot of use our of my folder/file comparison tools during all this. Found that one of my clients Solr didnt get updated when I tried to go to .05.

[Toby Mills]

Well guys - looks like theres a new vulnerability that I havent read up on yet. And a new HF-002 to address it (for 8207.28.05).

 

image.png708366 30.5 KB

 

The readme says basically now we need to get up to log4j version 2.16 instead of 2.15 rc2.

 

image.png937232 6.18 KB

 

@warren.hinchliffe - let me go look and see if they put a new one up for your release also:

 

Id say yes - theres a different one now. I presume - certainly possibly incorrectly - that the .28.01 through .28.04 are actually referring to hotfixes. So I think these are hotfixes you can apply after the hotfixes

Its a real moving target lately.

[Toby Mills]

From the log4j security page:

 

History

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.

[David Hall 5]

Hotfix 2 is now available for 8207.28.05

 

It contains the 2.16 release

log4j-1.2-api-2.16.0.jar

log4j-api-2.16.0.jar

log4j-core-2.16.0.jar

log4j-jcl-2.16.0.jar

log4j-jul-2.16.0.jar

log4j-slf4j-impl-2.16.0.jar

webfocus-caster-server-8207.28.05.jar

[Toby Mills]

Well just in case you are like me and about to deploy the log4j 2.16 in 8207.28.05 hotfix 2, you might want to wait a day or two.

ANOTHER new vulnerability has been found and that looks to have been addressed in log4j 2.17.

Apache Log4j Security Vulnerabilities

Since this seems to be a trend, let me mention that the following screenshots have a date at the top of it thats chopped off. This was released sometime after I looked yesterday Dec 17, 2021:

 

image.png1575493 52.7 KB

 

 

image.png1566323 48.8 KB

[Warren Hinchliffe]

To patch or not to patch.

That is the question.

We will patch to the newest for our version because of the xmas break.

[Toby Mills]

1 patch, 2 patch,

red patch blue patch

My next thing is to finish bringing 2 more client machines up to 8207.28.05. From there, Ill decide about the next step tomorrow. I need to have something in place before I leave for the holiday on Wednesday. It may be 2.16 is the best we can do in the short run. 2.17 might have to wait unless the military tells me its gotta be on there.

Beyond Compare has helped with the jar file upgrades. I just make my backups on one of my machines and then skip backing up on the others (since theyre all the same). Way faster to do it this way.

[David Hall 5]

I got the following from my Gold Support ASM

Based on Engineering assessment, which is ongoing, preliminary information is that WebFOCUS is not impacted by the new vulnerability in 2.16 that was reported by Apache. Please refer to TIBCOs company update statement for updates. Additionally and out of an abundance of caution, the upcoming TIBCO WebFOCUS 8.2.07.28.06 service pack will include log4j version 2.17.

Note the mention of the service pack (not hotfix)

[Toby Mills]

Thanks very much David - were just on basic support so we have way less visibility to whats going on in the product division.

Referring to the companys update statement doesnt tell us as much as you got to hear.

 

TIBCOs efforts continue to focus on delivering a remediation for Apache Log4J CVE-2021-44228 and CVE-2021-45046. We are aware of Apache Log4J CVE-2021-45105 and have begun investigating whether this CVE applies to TIBCO products. Information on TIBCO products potentially affected by CVE-2021-45105 will be forthcoming.

 

So I think Ill probably hold off on more manual patching. I bet they generate their new installer based .06 version during the night tonight or tomorrow.

Ive looked through the new TIBCO jars a little. Essentially it looks like they just need to update filenames in the CLASSPATHs that are internal to switch from the 2.16 versions to 2.17. Seems like Its not much of a stretch for them since they just had to do that for 2.15 -> 2.16.

Well hope to hear more news today.

[Bill Dykema]

Looks like a bit of a moving target with new issues being found with later versions of Log4J, but has anyone heard about a 8.2.06 patch being available at some point

[Manoj Chaurasia]

Hi Bill, for an 8206 (8206.33) hotfix, please open a case with TIBCO Support as per this article.

[Warren Hinchliffe]

I applied the 8207.28.04 Hotfix 001 patch this morning (yes its morning here).

May move to 8.2.07.28.06 next year. Not because of the fix, but some of the goodies in it.

[David Hall 5]

We have requested an 8206 fix for the log4j issue. We did open a case, we are waiting for the delivery. We were told possible availability would be today. However, I doubt it will be posted for anyone to download, so you will need to open a case.

Word of warning. The fix will be to the latest release of 8206. That release as of now is 8206.33. If you do not have this release, you will need to open a different case and ask for that release as well

Once you have both. You can 1) upgrade to 8206.33, 2) apply hotfix

We may be lucky and they may post an 8206.34 with the fix in place, but I am not holding my breath.

If you have not done it, open a case to get both the software and the fix

[Bill Dykema]

Thanks Melinda, we do have a case open. Unfortunately, we could be stuck at an earlier version because of some fixes put in for us by engineering that we are not sure ever made it into a later version of 8206.

[Garth Colasurdo]

Thanks for this info Melinda. Curiously, looking at the link, it seems to skip mention of 8207.27.

8207.27 is in the Hotfix downloads list, but hasnt received any updates since the summer. We do have a case open for a .27 Log4j fix.

(In our case _28 was released four days before our production update to 8207.27 [from 8203]. Not enough time for testing by our users prior to academic and fiscal reporting crunch time.)

[Manoj Chaurasia]

Hi Garth, Hotfixes for 8207.27 should be up on the support site today.

[Toby Mills]

Hi Garth

 

Looks like some hotfixes are there to consider now

[David Hall 5]

For others who are wondering, We finally got a copy of the 8206 log4j hotfix software.

There is a hotfix for the WebFOCUS client and another hotfix download for the WFRS.

Note: you must update the 8206 software to the 8206.33 release before following and applying the log4j remediation steps.

[SATHEESH B]

Received log4j hotfix for 8207.26 . Did any one apply the patch on 8207.26 My Customer environment is AIX and WebSphere. We have to create a war file and deploy it.

[David Hall 5]

For those who are contemplating manually applying the log4j fix in 8207.28, The 8207.28.06 release has been posted on the download site