log4j Exploit

Pulse Pulse Questions
#1

Hi all,

We have just published an article about the an exploit in the log4j logging library. Pulse 6 could be used to exploit the vulnerability but the attacker would need admin permissions in Pulse.

If you have Pulse 6 you should apply one of the fixes in the article.

2 Likes
#2

Hi @tryan ,

May I assume the log4j download version is 2.1.5+?

I tried to download today, it’s already 2.1.6.

image
image2874Γ—1120 630 KB

Regards

Tat

#3

Yep, 2.15 or greater (not 2.1.5).

#4

Tat,

The latest release is 2.16.0. Some initial changes were introduced in 2.15.0 to resolve the issue, and some more comprehensive changes were made in 2.16.0 and released yesterday.

https://logging.apache.org/log4j/2.x/changes-report.html

Tim

#5

I have updated the article. They they have completely removed the functionality that was the cause of the exploit.

#6

I know it says that PAW is affected but it seems ambiguous whether PAL is affected? Do you guys have any guidance on that?

#7

Hi @james.geraci,

From my understanding PAL local is not impacted, TM1Web uses version 1 of log4j and the server itself is C++. If you look in the install directory no v2 log4j jar files can be found. PAW and CA both have v2 jar files.

That should of course be confirmed by IBM.

#8

Hi @james.geraci,

See IBMs statement in Security Bulletin: IBM Planning Analytics 2.0: Apache log4j Vulnerability (CVE-2021-44228)? β€œWithin IBM Planning Analytics 2.0, only the IBM Planning Analytics Workspace component of IBM Planning Analytics is affected by a security vulnerability.”

If you are interested in Cognos Analytics (even just for CAM) see Security Bulletin: IBM Cognos Analytics: Apache log4j Vulnerability (CVE-2021-44228)? β€œIBM Cognos Analytics is affected by a security vulnerability. Apache Log4j is used by IBM Cognos Analytics as part of its logging infrastructure.”

#9

@tryan

This whole Log4j saga is getting even more interesting following discovery that 2.15 has a critical vulnerability 2.16 turned out to have high so 2.17 contains the fix for it:

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

Should we then just copy 2.17 to elasticsearch lib folder or whatever library is the most recent?

#10

Ξ—ΞΉ @pgrochola,

If log4j is recommending to go to 2.17. do so. I suggest to test it first in a dev environment.

Regards,

Erik

#11

We are testing the impact of 2.17 as well.

Regards,

Erik

#12

@pgrochola,

We performed tests with 2.17 and it is working fine. the suggestion now onwards is to deploy 2.16 or later.

Regards,

Erik

1 Like