12-13-2021 02:53 AM - edited 02-25-2022 12:14 AM
28 December 2021: The hotfixes for log4j are now available:
------------------------
Cloud:
------------------------
22 December 2021: Important update! Based on the latest information, adjusting the nolookup attribute is not enough. For more information, see https://logging.apache.org/log4j/2.x/security.html#
In addition to the initial instructions below, you should remove the following class from use: "JndiLookup.class". This can be done with the example PowerShell script below. As always, we recommend validating these changes in the development environment first before moving them to production.
Copy the script to your Notepad, save as a .ps1 file and run it in PowerShell.
# start script
Add-Type -AssemblyName 'System.IO.Compression';
$vus = 'D:\SAP\ContactCenter\VU';
gci $vus -Filter 'log4j2.xml' -Recurse | ForEach {($_ | gc -Raw | ForEach { $_ -replace '%msg%n', '%m{nolookups}%n' }) | sc $_.FullName -Verbose}
Get-ChildItem $vus -Filter 'log4j-core-*.jar' -Recurse | ForEach {Remove-File-From-Zip $_.FullName 'JndiLookup.class'}
function Remove-File-From-Zip {
[CmdletBinding()]
param (
[Parameter(Mandatory)]
[string]$zipfile,
[Parameter(Mandatory)]
[string[]]$files
)
Write-Output 'Opening: '$_.FullName;
$stream = New-Object IO.FileStream($zipfile, [IO.FileMode]::Open)
$mode = [IO.Compression.ZipArchiveMode]::Update
$zip = New-Object IO.Compression.ZipArchive($stream, $mode)
$deleted = $false;
($zip.Entries | ? { $files -contains $_.Name }) | % {
Write-Output "Deleting file '$_' from '$zipfile'";
$_.Delete();
$deleted = $true;
}
if (-not $deleted) {
Write-Output 'Nothing found';
}
$zip.Dispose()
$stream.Close()
$stream.Dispose()
}
# end script
The output should look like this:
Opening:
D:\SAP\ContactCenter\VU\VU_ECF_Agent\tomcat\webapps\ecfs\WEB-INF\lib\log4j-core-2.8.2.jar
Deleting file 'org/apache/logging/log4j/core/lookup/JndiLookup.class' from ' D:\SAP\ContactCenter\VU\VU_ECF_Agent\tomcat\webapps\ecfs\WEB-INF\lib\log4j-core-2.8.2.jar'
The recommendation is to do this as soon as possible. This also slightly affects hotfix plans:
-----------------------------------------
Original post 13 December 2021:
For more information, see:
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.randori.com/blog/cve-2021-44228/
Sinch development is working on this issue, and for now we recommend on-premise customers to do the following:
gci 'D:\SAP\ContactCenter\VU' -Filter 'log4j2.xml' -Recurse | ForEach {($_ | gc -Raw | ForEach { $_ -replace '%msg%n', '%m{nolookups}%n' }) | sc $_.FullName -Verbose}
For the environments of the cloud customers, these actions are carried out by Sinch.
12-22-2021 01:33 AM
TIP: Signing to community allows you to subscribe into interested topic. For example in this one there is three dots button on top left corner and also and arrow down button. Under those you can find subscribe button. This way you ensure that you get latest updates.
03-16-2022 03:29 AM
Hello,
as s solution for this we have installed hotfix 7.0.16.123 and have activated logging again.
Our customer asked me now, how this issue was resolved in the end?
Has Log4j been upgraded to a newer version (like in 21Q4 cloud release) with 7.0.16.123, or has Log4j dependency removed completly (like 22Q1 cloud release)? If upgraded, to which version?
Thanks.
03-16-2022 04:00 AM
Hi Thomas,
Good that you asked and here is the answer shortly from onprem point of view:
In other words we recommend customers upgrading to latest release or minimum to apply hotfix to mitigate the problem.
//Jukka