Strengthening Java Application Security Against Supply Chain Threats

The software Supply Chain is essential for developing applications today, but it also brings risks. Many developers use third-party libraries for their software, which can create security issues. If these libraries have flaws, they can be exploited by attackers. One notorious attack is called Log4Shell, which allowed code from a malicious source to run on the server. This paper discusses a new system that helps prevent such attacks in Java applications.

#The Problem

As software development has grown, the reliance on external code has increased. This introduces vulnerabilities, particularly when unverified code is run. Many recent attacks have targeted this weakness, exploiting flaws in popular libraries to execute harmful commands remotely. Traditional security methods may catch these issues during development but often fail to protect against threats during Runtime.

#The Solution

Our proposed system builds an AllowList of classes that are permitted to run in a Java application. This allowlist is created based on the software supply chain of the application. By ensuring that only trusted classes are executed, the system can block any unrecognized or modified classes at runtime.

#How the System Works

#Allowlist Creation

During the building phase of an application, the system scans all classes, creating a list known as the Bill of Materials Index (BOMI). This list includes classes from the core Java libraries, classes written by developers, and any dynamically generated classes.

1. Environment Classes: These are built-in Java classes. The system records the checksums for these classes, which serve as unique identifiers.

2. Supply Chain Classes: These classes come from third-party libraries. The system takes inventory of all the libraries and their classes to create a complete list.

3. Dynamic Classes: Java allows for the generation of classes while the application is running. The system monitors the application during testing to record any dynamically created classes.

#Runtime Monitoring

Once the BOMI is created, the application can be monitored during execution. A component called the SBOM Runtime Watchdog is activated. It checks each class that is loaded against the BOMI.

• If the class is on the BOMI and matches the checksum, it is allowed to run.
• If the class is not found or if the checksum does not match, the application is terminated immediately. This prevents any potentially harmful code from executing.

#Why It Matters

This system directly addresses a critical issue: the ability to execute unknown classes. By maintaining a strict allowlist and monitoring class loading, the system can effectively minimize the risk posed by dynamic class loading features in Java.

#Testing the System

To validate the effectiveness of our system, we tested it against three significant vulnerabilities commonly known in the security landscape.

1. Log4j: The Log4Shell vulnerability showed how attackers could execute malicious code via a logging library. Our system successfully prevented the execution of this malicious code by comparing it against the BOMI.

2. H2 Database: This database engine was also vulnerable to similar attacks. We replicated the conditions for a potential exploit and again found that our system stopped any harmful code from executing.

3. Apache Commons Configuration: Using the Nashorn JavaScript engine, which was bundled with Java, this vulnerability demonstrated how JavaScript code could lead to severe security issues. Our system effectively intercepted the malicious code before it could run.

#Real-World Applicability

We also evaluated our system on real-world applications to measure its impact and performance. We tested its compatibility with existing software, aiming to ensure that it does not interfere with legitimate operations.

1. PDFBox: This application manipulates PDF files and was tested under a workload that involved various PDF operations. Our system ran without any false positives, successfully identifying and allowing legitimate operations.

2. Ttorrent: A peer-to-peer downloading application was evaluated, successfully managing dynamic class generation without interruptions.

3. GraphHopper: This routing application was more challenging, revealing that some classes generated dynamically could not be captured due to their randomized nature. Even so, the system managed to block unauthorized code effectively.

#Performance Considerations

A key aspect of any security system is its performance impact. We measured the overhead introduced by our system during operations:

• During the initial startup and class verification, there is a noticeable overhead due to checksumming and verification processes.
• However, after the initial warm-up, the performance impact becomes minimal, making it suitable for long-running applications.

#Conclusion

The integration of our system into Java applications significantly enhances security against supply chain attacks exploiting dynamic code execution. By creating a detailed BOMI and actively monitoring class loading, we can effectively ensure the integrity of Java applications in a complex software landscape.

#Future Directions

Looking ahead, we aim to expand our system’s capabilities, focusing on the detection of hidden classes that current methodologies may overlook. We also plan to explore comparisons with other technologies that address similar security concerns. Overall, our approach lays a solid foundation for improving software security against evolving threats.