+6We are using Rapid 7 for Vulnerability scanning in our environment, and we are seeing a lot of "Vulnerability in the Oracle Java SE Hotspot component" vulns pop up pointing to some jar files inside Jetbrains apps/folders. The listed resolution is to update "Azul Zulu" and links to an Azul JDK page.
None of our users have installed the Azul OpenJDK, and I don't think I can update the .jar files inside the .app.
Has anyone else seen these vulnerabilities and know how to approach this?
+4Same vulnerability/issue reported by Rapid7 here. Have you been able to find a solution or determine the source of the issue?
+11We are seeing these now as well. Were you ever able to address these?
+4Good afternoon, everyone. I was both curious if there was a solution y'all have come up with and a solution I figured out.
So Azul Zulu as you may know is just a flavor of Java and Rapid7 has been reporting all the rt.jar and jrt-fs.jar files as evil with CVE's. Our solution was to just flat remove all of those files using a script and cleaning house in the Users folder and /Library/Java/JavaVirtualMachine/ folders. This worked great for us admins, but wreaked havoc for our corporate Dev's. We ran the script through a policy every day because managers wanted this handled pretty aggressively.
Ticket after ticket came straight to me for resolution. I have spent a few weeks trying different things. I believe I have it figured out after speaking with our Dev's on how Java stuff works. I had my thinking completely wrong on this. The removal of rt.jar and jrt-fs.jar files as we had been doing for a while is nothing but a bandaid. The devs told me that jar files are nothing but compressed files/wrapped files (please don't quote me there) and the Zulu Java is what I needed to concern myself with. This changed my way of thinking. One said think of jar files like a book and the vulnerable versions of Zulu as a psychotic person reading those books. Anything could happen. Here is my solution that seems to be working:
Utilize Patch Management to bring all Macs to the latest LTS versions of Zulu which are 8, 11, 17, & 21 as found on the Zulu download page and reported by patch management. First thing to do is to create the Patch Management policy and enable the Extension Attribute so Jamf can start collecting that information for future use. After this I downloaded the latest LTS version DMG's and uploaded the pkg's found inside of the DMG download after renaming them to something identifiable. I set up the Patch Management with the Definition and Patch Policies as normal and that started to do it's work of updating the many different versions of Zulu listed above. So far, almost everyone is happy. We still had to remove old versions, like really old versions that were released in 2014 and a few version 7's from 2013.
The following is my script used to search and find all non-LTS versions from the Mac:
#!/bin/bash
# Gracefully exit if something errors out.
set -e
# This script removes specific vulnerable Azul Zulu OpenJDK directories from a user's macOS computer,
# deletes them, and logs the output to "/private/tmp/deleted_zulu_directories.log".
# Determine the logged-in user.
loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
# Define the log file location in /private/tmp/ with the current date and time
logFile="/private/tmp/deleted_zulu_directories-$(date +"%Y-%m-%d_%H%M").log"
# Define the versions to remove
versions=(
"1" "2" "3" "4" "5" "6" "7"
"9" "10"
"12" "13" "14" "15" "16"
"18" "19" "20"
"22" "23"
)
# Function to remove directories
goSeekandDestroy() {
local DIR=$1
for version in "${versions[@]}"; do
for dir in "$DIR"/zulu-${version}.jdk; do
if [ -d "$dir" ]; then
echo "$(date '+%Y-%m-%d %H:%M:%S') - Removing directory: $dir" | tee -a "$logFile"
rm -rf "$dir"
else
echo "$(date '+%Y-%m-%d %H:%M:%S') - Directory not found: $dir" | tee -a "$logFile"
fi
done
done
}
# Clear the log file
echo "Deleted directories log - $(date)" > "$logFile"
# Remove directories from the user's home directory
goSeekandDestroy "/Users/$loggedInUser/Library/Java/JavaVirtualMachines"
# Remove directories from the /Library directory
goSeekandDestroy "/Library/Java/JavaVirtualMachines"
# Add additional directories here if needed:
# goSeekandDestroy "/directory"
# Print completion message
echo "Deletion complete. The log file is located at $logFile"
# Allow Jamf to collect log in Policy History
cat "$logFile"
This has worked for my org and me, so test, try, and adapt it to see if it does what you need it to do. Maybe even share it back if you have a better way of scripting this.
I hope this helps y'all out.
- Chris
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.