Patching Oracle Linux against CVE-2023-48795 Vulnerability on Air-Gapped Servers

Posted on by Ahmed Abdel Fattah

We’ve all been there. That email from the security team lands in your inbox, or a routine scan flags a new, critical vulnerability. This time, it’s CVE-2023-48795, also known as the “SSH Terrapin Prefix Truncation Weakness.” It sounds intimidating, and the thought of a man-in-the-middle attack.

For many, the fix is straightforward. But what if the server in question is one of your most secure assets—an offline, air-gapped machine running Oracle Linux 7.9?

This post walks through that exact real-world scenario, from identifying the problem to navigating the complexities of offline patching and understanding the quirks of enterprise Linux updates.

The Simple Fix: When Your Server Can See the Sun

On an internet-connected server, fixing Terrapin is usually a breeze. You connect, run a quick update, restart the service, and validate. It looks something like this:

# Update the OpenSSH packages
sudo yum update openssh

# Restart the SSH service for changes to take effect
sudo systemctl restart sshd

# Check your new version
ssh -V

After this, you’d run a vulnerability scanner to confirm the CVE is resolved. Simple, effective, and you’re back to your day.

The Plot Thickens: The Air-Gapped Server

But our target server is isolated from the internet. This is a common security posture for critical infrastructure, but it means yum update isn’t an option. So, how do we get the patch onto the machine?

The answer is to use an internet-connected “staging” machine to download the necessary files, transfer them over, and install them manually. This introduces our first challenge: what makes a good staging machine?

In our case, we had two options: an Oracle Linux 7.7 machine and a newer Oracle Linux 9.4 machine.

Your first instinct might be to use the newer OL9 machine, but this is a trap! Package dependencies (like core system libraries) are fundamentally different between major versions (OL7 vs. OL9). Packages downloaded for OL9 would fail spectacularly on an OL7 server.

The clear winner is the Oracle Linux 7.7 machine. Because it belongs to the same major family, its packages and dependencies are compatible with our target OL7.9 server.

The Step-by-Step Offline Patching Process

With our OL7.7 staging machine ready, here’s the game plan:

Step 1: Download the Packages and Their Friends (Dependencies)

On the internet-connected OL7.7 machine, we need to download not just the openssh packages, but all the other packages they depend on. Thankfully, yum has a tool for exactly this.

# First, ensure you have the 'yumdownloader' utility
sudo yum install yum-utils -y

# Create a clean directory for our update files
mkdir ~/offline-ssh-update
cd ~/offline-ssh-update

# Download the packages AND resolve all dependencies
# This is the most critical command in the process.
sudo yumdownloader --resolve openssh openssh-server openssh-clients

The --resolve flag is the magic ingredient, saving us from a frustrating game of “guess the dependency” later on.

Step 2: Transfer the Goods

Once the download is complete, you’ll have a folder full of RPM files. Copy this entire folder to a USB drive or transfer it via a secure, internal-only network share to your offline server.

Step 3: The Final Install

On the offline OL7.9 server, navigate to where you placed the RPM files. Using yum localinstall, you can install all the packages at once, and it will intelligently handle the dependencies from the files you’ve provided.

# Assuming the files are in /tmp/ssh-updates
cd /tmp/ssh-updates

# Use yum to install from the local RPM files
sudo yum localinstall *.rpm

After the installation completes, restart the SSH service to activate the patch:

sudo systemctl restart sshd

“Wait, Is This Right?” – A Moment of Confusion and Clarity

After following the steps, we ended up with these files:

  • openssh-7.4p1-23.0.3.el7_9.x86_64.rpm
  • openssh-clients-7.4p1-23.0.3.el7_9.x86_64.rpm
  • openssh-server-7.4p1-23.0.3.el7_9.x86_64.rpm

This is where a moment of doubt can creep in. “The latest OpenSSH is version 9.x. How can version 7.4 be the fix?”

This is a perfectly valid question, and the answer gets to the heart of what makes enterprise Linux so reliable: backporting.

Instead of replacing the entire OpenSSH package with a brand new major version (which could introduce breaking changes), Oracle’s engineers take the specific security fix from the newer code and apply it to their stable, supported version (7.4p1). The package is then re-released with a new build number, in this case, -23.0.3.el7_9.

So yes, openssh-7.4p1-23.0.3.el7_9 is absolutely the correct, patched version for Oracle Linux 7.9. You get the modern security fix without sacrificing the stability you rely on.

Mission Accomplished

By using a compatible staging machine, leveraging yumdownloader, and understanding the practice of backporting, we can confidently patch even our most secure, isolated systems. The final step is always to validate the fix with a scanner if possible, or by checking the installed RPM version against the official Oracle Linux Security Advisory (in this case, ELSA-2024-12158 and others) to close the loop.

Hopefully, this detailed walkthrough not only helps you solve this specific CVE but also demystifies the process of maintaining secure, offline Linux infrastructure.

(Feature image from: https://cyberhoot.com/blog/critical-advisory-openssh-remote-code-execution-vulnerability/)

Thanks
Ahmed

Leave a comment