Sensitive data leaks are a constant threat in enterprise software. Recently, IBM addressed a vulnerability in their Toolbox for Java—a popular toolkit for accessing IBM i server resources through Java applications. The issue, tracked as CVE-2022-43928 (IBM X-Force ID: 241675), affects the Db2 Mirror for i versions 7.4 and 7.5 and revolves around insecure memory management related to Java's String objects.

Below, we break down what this flaw is about, how it works, and what you've got to do to protect your applications.

Why Are Java Strings A Risk?

Java String objects are immutable, which means once you create them, you can't change their content. This is usually a good security practice but comes with a side effect: the content of any String lingers in memory until the Java Garbage Collector (GC) decides to clean it up.

If your application processes sensitive info—like database credentials, passwords, or private keys—using String, that data can sit in memory for far too long. A malicious actor who gains access to the system memory (think: memory dumps, JVM snapshots, etc.) could pull out that information, even though the application doesn't need it anymore.

How The IBM Toolbox Amplified This Issue

The IBM Toolbox for Java, especially within Db2 Mirror for i, used Java String objects to handle such sensitive info. This means sensitive database entries or credentials could stay readable in memory after active use.

Exploit Details: What an Attacker Could Do

Let's say an attacker can run a process on a system where your affected Java application is running. They could:

Extract and reuse that sensitive information.

This doesn't require exploiting a bug to get code execution—just access to memory, which could happen through other vulnerabilities or insider actions.

Problematic Way (Unsafe)

public class Db2MirrorConnection {
    public void authenticateUser(String username, String password) {
        // password stored as a String (unsafe)
        // ...
    }
}

In this scenario, password will remain in JVM memory after authentication.

public class Db2MirrorConnection {
    public void authenticateUser(String username, char[] password) {
        try {
            // Use password array for authentication, process as needed
        } finally {
            // Overwrite password after use
            Arrays.fill(password, '\');
        }
    }
}

By using a character array and overwriting it, you reduce the window that the password is exposed in memory.

IBM's Fix

IBM has fixed CVE-2022-43928 by reducing the lifetime of sensitive data in memory. While Java Strings can't be cleared, IBM now processes sensitive data in a way that minimizes residency time in memory. Internally, this often means switching from Strings to mutable arrays where possible and explicitly clearing or overwriting the data as soon as it's not needed.

Version 7.5

...using the IBM Toolbox for Java, you're at risk.

1. Update Immediately: IBM's security bulletin provides patched versions—retrieve the fix here.
2. Review Your Code: If you handle any sensitive data in your code, consider following best practices: prefer char[] over String, and clear memory quickly.

References and More Reading

- IBM Security Bulletin for CVE-2022-43928
- IBM X-Force Exchange: 241675
- [OWASP: Insecure Storage in Memory (Strings vs char[])](https://owasp.org/www-community/vulnerabilities/Insecure_Storage_of_Password_in_Memory)

Summary

CVE-2022-43928 is a reminder that even the languages and paradigms we trust most can introduce security issues if we're not careful. Always be mindful of how you handle sensitive data—not just how you store it, but how you process it in your code. Stick to best practices and keep your dependencies up to date to keep your systems secure.

Timeline

Published on: 04/07/2023 14:15:00 UTC
Last modified on: 04/13/2023 20:49:00 UTC