The days when we could feel confident that IBM i had no security vulnerabilities are very much over. A peek at the Common Vulnerabilities and Exposures (CVE) registry list proves it.

For security admins on Windows and Linux platforms, the Common Vulnerabilities and Exposures (CVE) registry has been common knowledge for a long time. But to IBM i admins, it may be a little less well known. When I worked in a multi-platform security team, we bragged that there were never any IBM i security vulnerabilities. Windows and Linux were riddled with them, but IBM i? Nope, never. We held our heads high with pride. However, in recent years, a few things have changed in the IBM i CVE landscape. One is that the platform has been getting more attention from folks trying to penetrate the system, whether they be bad actors or penetration testers. Another is that a lot of open-source, third-party software has been introduced to the system, allowing for innovation. This article aims to shed a little light on what CVEs are and how they can be used to your security advantage.

What Is a CVE?

The CVE registry is a list of cybersecurity vulnerabilities that is managed and was developed by the MITRE Corporation in 1999 in response to the need for standardizing how vulnerabilities and exposures are identified as they are discovered and publicly disclosed.

The National Institute of Standards and Technology (NIST) publishes these security vulnerabilities in the U.S. National Vulnerability Database (NVD) and adds additional information, such as a Common Vulnerability Scoring System (CVSS) score that rates the severity of the vulnerability. CVSS scores range from 0-10, with 0 being the most minimal severity and 10 being the maximum. It is generally recommended that any CVE entry with a score that is 7 or higher be addressed as soon as possible and that a regular schedule of applying fixes be maintained for less-critical vulnerabilities. Even though low-score vulnerabilities are not as easy to exploit or not as prevalent, they would not be reported if they could not do damage.

CVSS Score Range

0: Minimal severity

0.1–3.9: Low severity

4.0–6.9: Medium severity

7.0–8.9: High severity

9.0–10.0: Critical severity

NIST also provides the Security Content Automation Protocol (SCAP) and CVE content data feeds, which greatly improve the ability to integrate information from the database into automated processes and provide quicker access to security vulnerability disclosures.

Anatomy of a CVE Entry

For each CVE entry, you will find the following information in the National Vulnerability Database:

• CVE Identifier: A unique For example, CVE-2023-50314.
• CVE Description: A brief description of the security vulnerability.
• CVSS Score: A score ranking the severity of the vulnerability, ranging from 0 to 10.
• Publishing Authority: This is the CVE Numbering Authority (CNA) that first publicly disclosed the vulnerability. CNAs are major OS vendors, security researchers, or research organizations (for example, IBM, Microsoft, Google, etc.).
• Affected Product Details: The affected operating system or application is identified in the CVE entry.
• Remediation: If there is a patch available or any manual remediation steps known to fix the vulnerability, this information will be listed.
• Pertinent Information: Additional information may be listed if there are websites that have published more documentation or advisories on the issue.

Sample CVE: https://www.cve.org/CVERecord?id=CVE-2023-50314

IBM i and CVEs

Due to the solid architecture of the IBM i operating system, there is quite a noticeable difference in the number of security vulnerabilities on the system versus other operating systems. However, the need to be vigilant remains.

With technology advancements that have opened up IBM i to increased interoperability, such as the PASE environment and all the open-source, third-party applications that can be installed there, as well as the number of web applications connecting to the system, the additional risks inherent to those applications have entered the system as well.

Add that to the vast increase in global cybercriminal activity and the need to protect against it, and you will notice that the IBM i security playing field of 15+ years ago is not nearly the same as it used to be, highlighting the benefit of taking advantage of security vulnerability information for the IBM i platform.

Recently, a wide range of IBM i security vulnerabilities have been reported on a fairly regular basis via the IBM i Security Bulletins.

Examples

Here is an example of a CVE report listed in the National Vulnerability Database and the subsequent security bulletin produced by IBM regarding a vulnerability that can lead to a Denial-of-Service (DOS) attack.

CVE-2024-31879

• https://nvd.nist.gov/vuln/detail/CVE-2024-31879
• https://www.ibm.com/support/pages/security-bulletin-ibm-i-vulnerable-denial-service-network-ports-due-deserialization-untrusted-data-management-central-cve-2024-31879

You can tell from this report that it is a high-severity vulnerability affecting IBM i versions 7.2, 7.3, and 7.4. The PTFs released for 5770-SS1 Option 3 to patch the vulnerability are listed in the bulletin as well.

Here is another example of a CVE report listed in the NVD and IBM’s subsequent security bulletin. It refers to a high severity vulnerability that can allow IBM i privilege escalation due to the ability to configure a physical file trigger on IBM i versions 7.2, 7.3, 7.4. and 7.5. Likewise, the PTFs to resolve the vulnerability are listed.

CVE-2024-27275

• https://nvd.nist.gov/vuln/detail/CVE-2024-27275
• https://www.ibm.com/support/pages/security-bulletin-ibm-i-vulnerable-privilege-escalation-due-ability-configure-physical-file-trigger-db2-ibm-i-cve-2024-27275

OS and Software Fixes and Patches

Also important to note is that keeping up with current OS and software versions is critical to securing your system, since IBM and other vendors do not always release fixes to patch security vulnerabilities on older releases. Security vulnerabilities that are now being discovered and made public may have been existent in the operating system or application for a long time, but unsupported versions of the OS or licensed product are not likely to have fixes created to patch them.

The Need to Keep Up: CVE Monitoring and Remediation

The public disclosure of security vulnerabilities is certainly a sort of double-edged sword in that, as vulnerabilities are publicized with the intention of providing information for us to beef up our security, they are also a playground for cybercriminals to quickly gain information to be used against us as they craft ways to exploit the vulnerabilities. Hackers and cybercriminals actively scan for published vulnerabilities on servers and take advantage of them to gain unauthorized access to sensitive data. Security research data shows that vulnerabilities are exploited within 4-44 days of publication, and some researchers claim that 25% of high-risk vulnerabilities are exploited within 24 hours. Therefore, it is crucial to monitor for CVE entries applicable to your servers on a daily basis. This should include your operating system and any third-party software used on your servers.

To keep up with security-related notifications published by IBM, it is highly recommended you subscribe to receive IBM i Security Bulletins. You can subscribe to these notifications here: https://www.ibm.com/support/pages/node/718119

Keeping up with patches is a constant battle, but is crucial to do so. This fundamental practice cannot be overstated. Unpatched machines are regularly the weak point used to gain unauthorized access to corporate networks in highly publicized cybersecurity breaches, which also points to the fact that maintaining a solid inventory of your IT assets (both hardware and software, including licensed products and third-party applications) is the first step to ensuring your systems are kept up to date. Many times, an old test system is sitting in a lab somewhere and gets forgotten about, but it remains publicly accessible from the internet and is a sitting duck just waiting for a cybercriminal to discover. That old test system could also be an IBM i LPAR sitting on your network, also needing attention.

With the uptick of CVE-related IBM i vulnerabilities, you must keep up to date with patching your system by applying critical fixes. Get into the habit of applying fixes for CVEs with higher CVSS scores as soon as possible and apply fixes for lower-severity CVEs on a regularly scheduled basis.

Fixes related to the OS and IBM i licensed products can be downloaded from Fix Central and applied. 

Fixes related to third-party libraries need to be obtained from the applicable vendors.

The Answer

So, should you care about CVEs on IBM i? Yes! You may never know if your diligence in protecting your systems saved you from a security breach, but you will definitely know if a known CVE was exploited. Keep at it!