OWASP - Secure Coding Practices - Memory Management

In this article, I will briefly cover the OWASP secure coding practices for Memory Management with examples from Java.

Here's the checklist for Memory Management:

Memory management

• Utilize input and output controls for untrusted data
• Check that the buffer is as large as specified
• When using functions that accept a number of bytes ensure that NULL termination is handled correctly
• Check buffer boundaries if calling the function in a loop and protect against overflow
• Truncate all input strings to a reasonable length before passing them to other functions
• Specifically close resources, don’t rely on garbage collection
• Use non-executable stacks when available
• Avoid the use of known vulnerable functions
• Properly free allocated memory upon the completion of functions and at all exit points
• Overwrite any sensitive information stored in allocated memory at all exit points from the function

Utilize Input and Output Controls for Untrusted Data

Always validate and sanitize any input that comes from untrusted sources to prevent buffer overflows and other security vulnerabilities.

For example,

Another example,

    public void saveUserData(String username, String password) throws SQLException {
        // Sanitize inputs to prevent SQL injection
        username = username.trim(); // Remove leading/trailing spaces
        password = password.trim(); // Remove leading/trailing spaces

        // Use prepared statements for safe database interaction
        String sql = "INSERT INTO users (username, password) VALUES (?, ?)";
        try (Connection conn = Database.getConnection();
             PreparedStatement pstmt = conn.prepareStatement(sql)) {
            pstmt.setString(1, username);
            pstmt.setString(2, password);
            pstmt.executeUpdate();
        }
    }        

Check that the Buffer is as Large as Specified

When allocating buffers, ensure that the buffer size matches the expected input size.

For example,

Ensure NULL Termination is Handled Correctly

When dealing with byte arrays or strings, ensure they are properly null-terminated if necessary.

For example,

Check Buffer Boundaries if Calling the Function in a Loop and Protect Against Overflow

When processing data in loops, check the boundaries of arrays or collections to prevent overflow or out-of-bounds exceptions.

In Java, while you have built-in safety mechanisms (like exceptions), you should still perform checks.

Truncate All Input Strings to a Reasonable Length

Always truncate input strings to a reasonable length to avoid buffer overflow and excessive memory use.

For example,

Specifically Close Resources, Don’t Rely on Garbage Collection

Explicitly close resources like file streams and database connections to avoid memory leaks.

For example,

Note: Regardless of the outcome, the BufferedReader is closed automatically when the try block exits.        

Use Non-Executable Stacks When Available

Using non-executable stacks is an important security measure aimed at mitigating certain types of attacks, particularly buffer overflow attacks. This approach involves marking the stack memory as non-executable, which means that even if an attacker manages to inject malicious code onto the stack, the operating system will prevent it from being executed.

By marking the stack as non-executable, the operating system enforces a policy where code cannot be executed from the stack memory. This significantly reduces the risk of successful buffer overflow attacks.        

Non-executable stack support is typically provided by modern operating systems (e.g., Linux, Windows, macOS) and can be enabled via compiler options or operating system settings.

In Java, memory management is handled by the JVM, which provides inherent protections against buffer overflows. However, if you were to interact with native code (via JNI, for example), it’s crucial to ensure that non-executable stack policies are followed.

If you have JNI code that calls native C/C++ functions, ensure you compile it with stack protections.

Avoid the Use of Known Vulnerable Functions

Stay away from functions or APIs known to have vulnerabilities. Always use safe alternatives.

For example, avoid using Runtime.exec() for executing system commands directly, as it can lead to command injection vulnerabilities. Instead, use ProcessBuilder which provides better control over process execution.

Properly Free Allocated Memory Upon Completion of Functions

In Java, you don’t manually free memory, but you should ensure that references are cleared to allow for garbage collection.

For example,

Also, weak references and soft references where applicable.

A weak reference allows the referenced object to be collected by the garbage collector when there are no strong references to it. This means that an object referenced by a weak reference can be garbage-collected at any time, even if the weak reference itself still exists. Weak references are useful for implementing caches where you want to hold onto objects only as long as they are needed, and you want them to be reclaimed when memory is low.

 Map<String, WeakReference<Object>> weakCache = new HashMap<>();

        // Creating a strong reference
        Object strongObject = new Object();
        weakCache.put("key", new WeakReference<>(strongObject));

        // Clear strong reference
        strongObject = null;

        // Suggest garbage collection
        System.gc();

        // Retrieve the weak reference
        WeakReference<Object> weakRef = weakCache.get("key");
        Object retrievedObject = weakRef.get();

        if (retrievedObject == null) {
            System.out.println("The object has been garbage collected.");
        } else {
            System.out.println("The object is still available.");
        }        

Soft references are similar to weak references, but they are more resilient. An object referenced by a soft reference is eligible for garbage collection only when the JVM is about to run out of memory. This makes soft references ideal for implementing memory-sensitive caches. Soft references are useful when you want to cache objects that are expensive to create but can be recreated if necessary, provided there is enough memory available.

 Map<String, SoftReference<Object>> softCache = new HashMap<>();

        // Creating a strong reference
        Object expensiveObject = new Object();
        softCache.put("key", new SoftReference<>(expensiveObject));

        // Clear strong reference
        expensiveObject = null;

        // Suggest garbage collection
        System.gc();

        // Retrieve the soft reference
        SoftReference<Object> softRef = softCache.get("key");
        Object retrievedObject = softRef.get();

        if (retrievedObject == null) {
            System.out.println("The object has been garbage collected.");
        } else {
            System.out.println("The object is still available.");
        }        

Overwrite Sensitive Information Stored in Allocated Memory

Before releasing sensitive information from memory, overwrite it to prevent potential leakage. When sensitive data is no longer needed, simply allowing it to be garbage collected or leaving it in memory can lead to potential security vulnerabilities.

Use Character Arrays for Sensitive Data

Instead of using immutable types like String in Java, which store data in a way that may not be easily cleared from memory, use a mutable type such as a character array.

For example,

 // Store sensitive information in a char array
        char[] password = new char[]{'p', 'a', 's', 's', 'w', 'o', 'r', 'd'};
        
        // Process the password...

        // Overwrite the sensitive information
        java.util.Arrays.fill(password, '\0'); // Clear the array        

Overwriting Data at Exit Points

Always ensure that sensitive data is cleared before exiting a method, especially when sensitive data is being handled in temporary variables or data structures.

 char[] sensitiveData = new char[256];
    // Assume sensitiveData is filled with sensitive information

    try {
        // Process sensitive data...
    } finally {
        // Overwrite sensitive data before exiting
        java.util.Arrays.fill(sensitiveData, '\0');
    }        

Also, consider using libraries that support Secure Memory Management.

Conclusion

By adhering to the above-mentioned OWASP secure coding practices for memory management in Java, you can significantly improve the security and stability of your applications. It’s important to remain vigilant and proactive in identifying potential vulnerabilities, ensuring robust input validation, and managing resources effectively.