Log4j Defect - It's Patched!

in

I wrote an article back in January (Log4j MID Server Fix Script) regarding Log4j defect on MID servers where they had a vulnerable version of the Log4j jar files on them. Great news - the issue has now been patched for good!

As of Rome Patch 7 and San Diego Patch 1, MID servers are now packaged with Log4j version 2.17.1 which is the currently safe version of the library.

All you need to do is make sure to upgrade your instance version to one of those patches or higher, and then also upgrade your MID server (typically happens automatically), and then you’re set.

I haven’t seen much official information posted that it was fixed, but will be sure to update the article if I find reference to an official announcement.

I also wanted to include as a bonus some instructions on how to verify the version of jar files on your MID server!

  1. Log into the MID server

  2. Open a CMD terminal as an administrator

  3. Type in the following commands:

    > F:

    > cd: D:\MIDServer\agent\jre\bin\

    > jar xf D:\MIDServer\agent\lib\log4j-core.jar

  4. Navigate to to D:\MIDServer\agent\jre\bin\META-INF\MANIFEST.MF file

  5. Open with a text editor, and verify the version number (ex: in the case of Log4j we want 2.17.1)

Note: After completing the instructions you can delete the META-INF folder that is created.

Log4j MID Server Fix Script

in ,

I know many people have been scrambling after the announcement of the Log4J vulnerability, and ServiceNow is not unscathed entirely. The MID server packages that are provided by ServiceNow, even in the latest version at the time of writing contain the vulnerability as a dependency, even though they don’t claim to use them. If you’re on the current MID server patch your Log4J is probably like version 2.14 or older and you need this fix.

The only workaround is to manually stop the service, delete and replace the jar files, and restart the service (described on KB1001211). Rinse and repeat for every MID server, and after every single patch or upgrade to the system, until ServiceNow decides to update it.

If you’re like me and have started going a little crazy, I’ve come up with a decent partially scripted solution for at least Windows MID servers! I hope others can make use of this trick to remediate their issue in a quicker and consistent manner.

Step 1. Download the latest jars of Log4j that are secure from logging.apache.org (currently v2.17.1). Save the ZIP to your desktop, extract and locate the log4j-api.jar, log4j-core.jar, and log4j-slf4j-impl.jar files.
Note: If they aren’t renamed exactly like log4j-core.jar, you will need to rename the file manually.

Step 2. Create a Local update set in your instance.

Step 3. Upload the 3 Jar files as a MID Server Jar file. Navigate to MID Server > JAR Files, click New, and fill out the name, version, description, and upload the file and save. Repeat for the 3 jar files.

Step 4. Create this MID server script file with the name as “Log4j.ps1” and this as the script:

#Run the following command using admin powershell terminal
#Usage>."D:\MyMIDServer\agent\scripts\Log4j.ps1"

#Primary MID Server Install path
$scriptsPath = split-path -parent $MyInvocation.MyCommand.Definition
$agentPath = split-path -parent $scriptsPath
Write-Output "Auto detected agent path as $agentPath"

#Path where all the new jars are located
$extlib = $agentPath + "\extlib\"

$startbat = $agentPath + "\start.bat"
$stopbat = $agentPath + "\stop.bat"

$extfile1 = $extlib + "log4j-api.jar"
$extfile2 = $extlib + "log4j-core.jar"
$extfile3 = $extlib + "log4j-slf4j-impl.jar"
$mainlib = $agentPath + "\lib\"
$file1 = $mainlib + "log4j-api.jar"
$file2 = $mainlib + "log4j-core.jar"
$file3 = $mainlib + "log4j-slf4j-impl.jar"

$file1exist = Test-Path $extfile1
$file2exist = Test-Path $extfile2
$file3exist = Test-Path $extfile3
#Write-Host "($file1exist) -and ($file2exist) -and ($file3exist)"

if (($file1exist) -and ($file2exist) -and ($file3exist)){
  Write-Output "Stopping MID Server Process"
  Start-Process -FilePath $stopbat -Wait -NoNewWindow

  Remove-Item -Path $file1 -Force
  Remove-Item -Path $file2 -Force
  Remove-Item -Path $file3 -Force
  Write-Output "Old Jar Files Removed successfully."

  Copy-Item -Path $extfile1 -Destination $mainlib
  Copy-Item -Path $extfile2 -Destination $mainlib
  Copy-Item -Path $extfile3 -Destination $mainlib
  Write-Output "New Jar Files Copied successfully."

  Start-Sleep -Seconds 1.5
  Write-Output "Starting MID Server Process"
  Start-Process -FilePath $startbat -Wait -NoNewWindow

  Clear-RecycleBin -DriveLetter D -Force -ErrorAction SilentlyContinue
  Get-ChildItem "D:`$Recycle.bin\" -Force | Remove-Item -Recurse -force
  Write-Output "Recycle Bin cleared successfully."
}else{
  Write-Output "New Jar files not detected in extlib folder, restarting MID"
  Start-Process -FilePath $stopbat -Wait -NoNewWindow
  Start-Sleep -Seconds 1.5
  Start-Process -FilePath $startbat -Wait -NoNewWindow
  Write-Output "Re-run script after Jar files have been propogated"
}

Step 5. Restart the MID server service so it force syncs the files.

Step 6. Remote into the server, or connect remotely using PowerShell.

Step 7. Open Powershell terminal as an admin and execute the line below. You will need to change the path to whatever path the MID server agent folder is using.

>. "D:\MyMIDServer\agent\scripts\Log4j.ps1"

Step 8. Validate the results. Open the lib folder and see the updated dates on the jar files.

Step 9. Close and move your update set and re-do steps 5-8 for any other environments and MID servers

My script includes some logic to auto-detect the folder, and detect if the jars are synced, otherwise it just restarts the service. The script also includes logic to clear the recycle bin, since the file can still be found even if in the recycle bin. If you are not using the D drive, you will need to slightly update the two lines to whichever drive you are using.

Also a word of caution, just deleting the log4j jar files without replacing will break the MID server service from starting all together. We can only hope that ServiceNow properly patches this soon.