Create a text file, where you list the files to clean on this server e.g. c:\fix\filetofix.txt
Create a new powershell file, jarupdate.ps1, with this content:
# set location of 7z program
$7zip = "C:\Program Files\7-Zip\7z.exe"
# run the script on the source machine
# get files from list to clean
$file2fix= Get-Content -Path "c:\fix\filetofix.txt"
foreach ($thefile in $file2fix)
{
Write-Host "Currently the script is cleaning " $thefile
& $7zip d "$($thefile)" "org/apache/logging/log4j/core/lookup/JndiLookup.class"
}
Get approval to do the update on the Cognos server.
Stop all IBM Cognos services.
Check that no JAVA process is still around.
Start POWERSHELL as administrator
Go to you c:\fix folder
Enter command: .\jarupdate.ps1
The output will be similar to this;
Reboot the server.
Test that Cognos still works.
Repeat on all effected servers.
If you have checked the size of the jar file before clean, you should see a difference after clean.
Change to the directory where you have downloaded the interim fix.
Decompress the .tar.gz file. If you are using WinZip®, select the option “use folder names”.
Stop Internet Information Services (IIS) Manager (the Default Web Site).
Shut down the IBM Cognos Controller Consolidation COM+ application through Component Services.
Stop the following services through the Services Manager.
Check that you have a back up of the cognos content store and controller database.
If your IBM Cognos Controller environment is customized, back up the entire IBM Cognos Controller location.
Go to the location where you downloaded and extracted the files.
Go to the win64h directory and double-click the issetup.exe file.
Open IBM Cognos Configuration, save the configuration, and then start the IBM Cognos service.
Open Controller Configuration, and check that the values are there, special for Server Authentication and Client Distribution Server Configuration.
If you have a distributed environment, repeat these steps for all remaining IBM Cognos Controller servers.
Start the Internet Information Services (IIS) Manager (the Default Web Site).
Reboot your windows server.
When you check in Cognos Controller client under help – system information – you see the version number there. Cognos Controller Version depend on the client you have installed.
In the transfer log you can find lines like this:
Condition “File “d:\Program Files\ibm\cognos\ccr_64\fcmweb\wlp\usr\servers\fcm.reports\apps\fcm.reports-rest.war\WEB-INF\lib\log4j-api-2.5.jar” exists” evaluated to true.
IBM is developing a “non-upgrade” option for “On Prem” Cognos Analytics customers that will patch the system and allow customers to remain on their current applicable version. Cognos Controller customer have to upgrade to latest version, or patch the faulty jar files themselves. But IBM is developing a “no-upgrade” option for “On Prem” customers that will patch the system and allow customers to remain on their current applicable version. Check IBM page https://www.ibm.com/support/pages/node/6528580
Place the file in c:\temp and start a powershell session:
.\check.ps1 > result.txt
Run the file with pipe the result to a text file, so you later easy can check what files can be an issue.
The command will check in jar files if they have the string JndiLookup.class
It will list the jar files that can have the issue, one example is C:\Program Files\ibm\cognos\analytics\bin\ThirdPartyCertificateTool.jar. Think that this program is not running all the time, it is only used when you use the tool from the command line. Then this jar file have a very little risk. It is worse for web-servers and web applications that run all the time.
You can unzip a jar file, to check its content.
If you remove the file JndiLookup.class and zip it back to a JAR file, you have cleaned the program.
Within IBM Planning Analytics 2.0, only the IBM Planning Analytics Workspace component of IBM Planning Analytics is affected by a security vulnerability. Apache Log4j is used by IBM Planning Analytics Workspace as part of its logging infrastructure. This bulletin addresses the exposure to the Apache Log4j (CVE-2021-44228) vulnerability.
Log4j 1.2.17 and 1.x does not contain any of the same lookup / template evaluation code, and the only class related to JNDI (JMSAppender) does not appear to connect to user-controlled remote systems based on log events. Older version of Cognos Controller that uses log4j-1.2.7.jar, does not have the same issue.
By sending a specially crafted code string, an attacker could exploit this vulnerability to load arbitrary Java code on the server and take complete control of the system. The attacker must get the Cognos Logger software to process a string to the log file, that active the function JNDI to contact LDAP server xxxx and download information, that in real can be java code, and execute it. Gives the possibility to install Trojans and other software, but he need to trick cognos to send the information to the logger.
Things you can do:
Ensure that the Cognos servers do not have contact with Internet, so any application on the server can reach out and download other software.
Creating a default-deny firewall rule will prevent servers from creating unapproved connections and can help reduce your risk of a compromise.
Ensure that only the people and computers that need it, have access to your cognos servers.
You can use tools, to see if you have the vulnerability;
Log4j is a tool to create log files, used by WebSphere and maybe Cognos software.
Check version of WebSphere with this command:
Above is from CA11.1.x CM_version=11.1.7-41.
In a CMD prompt, go to the java bin folder (path depends on version of Cognos Analytics)
Enter command C:\Program Files\ibm\cognos\analytics\wlp\bin\productinfo version
CA11 uses WebSphere Liberty Server, where the version number is the year it was released. WebSphere Application Server (WAS) latest version is 9, that should correspond to WLP 20.
You can search your cognos folder, to see if you have Log4j files that can contain this issue.
You will find it in several folders, but it is only the top one \bin that is the default. The others are cached versions in folders like C:\Program Files\ibm\cognos\analytics\wlp\usr\servers\cognosserver\workarea\org.eclipse.osgi\61\data\cache\com.ibm.ws.app.manager_157\.cache\WEB-INF\lib
Log4j-core and Log4j-api can contain this issue. Above picture from CA11, we see that we use version 2.7 of Log4j program. That is old, so the LOG4J_FORMAT_MSG_NO_LOOKUPS parameter will not work.
“the mitigation is to remove the JndiLookup class from the classpath, with command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. ”
Stop the IBM Cognos service.
Copy the log4j-core-2.7.jar file to a new folder e.g. c:\tempfix
Unzip the jar file.
Go down in the unzipped folder structure to C:\tempfix\log4j-core-2.7\org\apache\logging\log4j\core\lookup folder
Remove the file JndiLookup.class
Go back to your top folder, and zip it again.
Rename your log4j-core-2.7.jar to log4j-core-2.7.org.jar ( to keep a backup ).
Rename your log4j-core-2.7.zip file to log4j-core-2.7.jar.
Copy the new log4j-core-2.7.jar file to your C:\Program Files\ibm\cognos\analytics\bin folder.
Start IBM Cognos.
Check that you can login and run reports.
The Log4j is used to create the cognosserver.log files, so carefully check that the log files work as expected.
Copy the following files to the <VM_Manager_Tool_home_dir>/lib/ directory.
log4j-api-2.15.0.jar
log4j-core-2.15.0.jar
Stop the VM Manager Tool by using the -stop switch of the <VM_Manager_Tool_home_dir>/vmman.sh|bat script. For more information, see: VM Manager Tool command-line options.
Remove the following JAR files from the <VM_Manager_Tool_home_dir>/lib/ directory.
log4j-api-2.13.3.jar
log4j-core-2.13.3.jar
Depending on your operating system, modify one of the following files.
LINUX: In the <VM_Manager_Tool_home_dir>/vmman.sh file, find the following lines:
VMM_CLASS_PATH=$VMM_CLASS_PATH:$VMM_LOCAL_LIB/log4j-api-2.13.3.jar
VMM_CLASS_PATH=$VMM_CLASS_PATH:$VMM_LOCAL_LIB/log4j-core-2.13.3.jarChange them to:
VMM_CLASS_PATH=$VMM_CLASS_PATH:$VMM_LOCAL_LIB/log4j-api-2.15.0.jar
VMM_CLASS_PATH=$VMM_CLASS_PATH:$VMM_LOCAL_LIB/log4j-core-2.15.0.jar
WINDOWS: In the <VM_Manager_Tool_home_dir>/vmman.bat file, find the following lines:
SET VMM_CLASS_PATH=%VMM_CLASS_PATH%;%VMM_LOCAL_LIB%/log4j-api-2.13.3.jar
SET VMM_CLASS_PATH=%VMM_CLASS_PATH%;%VMM_LOCAL_LIB%/log4j-core-2.13.3.jarChange them to:
SET VMM_CLASS_PATH=%VMM_CLASS_PATH%;%VMM_LOCAL_LIB%/log4j-api-2.15.0.jar
SET VMM_CLASS_PATH=%VMM_CLASS_PATH%;%VMM_LOCAL_LIB%/log4j-core-2.15.0.jar
Start the VM Manager Tool by using -run switch of the <VM_Manager_Tool_home_dir>/vmman.sh|bat script. For more information, see: VM Manager Tool command-line options.
Workaround 2. Mitigate the issue on the current version of the Log4j library included in VM Manager Tool in versions 9.2.21.0 – 9.2.25.0 by the configuration change
Depending on your operating system, run one of the following:
LINUX: In the <VM_Manager_Tool_home_dir>/vmman.sh file, find the following line. It might not contain all the parameters starting with -D string, for example, it might not contain the -Dsun.net.http.allowRestrictedHeaders=true substring.VMM_PROPERTIES_DEFS=”-Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1 -Dcom.ibm.jsse2.disableSSLv3=false -Dcom.ibm.tools.attach.enable=no -Dsun.net.http.allowRestrictedHeaders=true”Add the following text at the end of the found line, just before the double quotation mark that ends this line.“ -Dlog4j2.formatMsgNoLookups=true” (including the space character at the beginning of the text)For example:
VMM_PROPERTIES_DEFS=”-Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1 -Dcom.ibm.jsse2.disableSSLv3=false -Dcom.ibm.tools.attach.enable=no -Dsun.net.http.allowRestrictedHeaders=true -Dlog4j2.formatMsgNoLookups=true“
WINDOWS: In the <VM_Manager_Tool_home_dir>/vmman.bat file, add the following entry as the last line of the ####### PROPERTIES DEFINITONS ####### section:SET VMM_PROPERTIES_DEFS=%VMM_PROPERTIES_DEFS% -Dlog4j2.formatMsgNoLookups=true
Stop the VM Manager Tool by using the -stop switch of the <VM_Manager_Tool_home_dir>/vmman.sh|bat script. For more information, see: VM Manager Tool command-line options.
Start the VM Manager Tool by using the -run switch of the <VM_Manager_Tool_home_dir>/vmman.sh|bat script. For more information, see: VM Manager Tool command-line options.
IBM X-Force also has provided an analysis of the Log4j vulnerability, which can be found on the IBM Security Intelligence blog.
You have to decide how you will handle this possible threat in your organization.
This is only a list of information, on the subject.
You should check your logs from your antivirus / firewall software, if you are already compromise.
by Roger·Comments Off on Changes to tm1web is not updated
Product:
Planning Analytics 2.0.9.10
Microsoft Windows 2016 server
Issue:
Changes is made to tm1web_config.xml file to pre-populate the HOST name field, so the user do not need to select adminhost before getting a list of applications. But the change is not visible when you browse to http://tm1webservername.domain.com:9511/tm1web/
The configuration parameters for IBM® Planning Analytics TM1® Web are stored in the tm1web_config.xml file.
The tm1web_config.xml file is located in the following location:
You can edit the file to add several adminhostservers, separated by semicolon.
<!-- If set, users will not be asked to enter Admin Host during login. -->
<add key="AdminHostName" value="tm1server1.domain.com;tm1server2.domain.com;tm1server3.domain.com" />
Solution:
You must close the notepad program that you use to edit the tm1web_config.xml, before the TM1 Web service will be able to read the file and use the changes.
You do not need to restart the service “IBM Planning Analytics Spreadsheet Services” for the changes to take affect.
To troubleshoot; check the log file tm1web.log in folder D:\Program Files\ibm\cognos\tm1web\webapps\tm1web\WEB-INF\logs. You may have this error in it;
Exception Error: ‘d:\Program Files\ibm\cognos\tm1web\webapps\tm1web\WEB-INF\configuration\tm1web_config.xml (The process cannot access the file because it is being used by another process.)’
WHILE [CCLMsg: system text=’loading TM1Web configuration from file ‘d:\Program Files\ibm\cognos\tm1web\webapps\tm1web\WEB-INF\configuration\tm1web_config.xml”]
‘d:\Program Files\ibm\cognos\tm1web\webapps\tm1web\WEB-INF\configuration\tm1web_config.xml (The process cannot access the file because it is being used by another process.)’
WHILE [CCLMsg: system text=’loading TM1Web configuration from file ‘d:\Program Files\ibm\cognos\tm1web\webapps\tm1web\WEB-INF\configuration\tm1web_config.xml”]
at com.ibm.cognos.tm1.web.shares.TM1WebConfig.loadConfigFile(TM1WebConfig.java:245)
at com.ibm.cognos.tm1.web.shares.TM1WebConfig.access$100(TM1WebConfig.java:58)
at com.ibm.cognos.tm1.web.shares.TM1WebConfig$1.update(TM1WebConfig.java:176)
at com.ibm.cognos.tm1.web.shares.TM1WebConfig$1.update(TM1WebConfig.java:171)
at com.ibm.cognos.tm1.observe.Observable.notifyObservers(Observable.java:30)
at com.ibm.cognos.tm1.file.Watcher.watchFileChanges(Watcher.java:86)
at com.ibm.cognos.tm1.file.Watcher.access$300(Watcher.java:16)
at com.ibm.cognos.tm1.file.Watcher$FileWatcher.run(Watcher.java:99)
at java.lang.Thread.run(Thread.java:822)
Caused by: java.io.FileNotFoundException: d:\Program Files\ibm\cognos\tm1web\webapps\tm1web\WEB-INF\configuration\tm1web_config.xml (The process cannot access the file because it is being used by another process.)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:212)
at java.io.FileInputStream.<init>(FileInputStream.java:152)
at com.ibm.cognos.tm1.web.shares.TM1WebConfig.loadConfigFile(TM1WebConfig.java:242)
AdminHostName If set, users are not asked to enter a value for Admin Host during login.
Other values you can change for tm1web:
<!-- CubeViewerRowPageSize: Number of rows to fetch in a page of cubeviewer -->
<add key="CubeViewerRowPageSize" value="500" />
<!-- CubeViewerColumnPageSize: Number of columns to fetch in a page of cubeviewer -->
<add key="CubeViewerColumnPageSize" value="100" />
<!-- MaximumSheetsForExport: Maximum number of sheets allowed to Export -->
<add key="MaximumSheetsForExport" value="80" />
