The Used, the Bloated, and the Vulnerable: Reducing the Attack Surface of an Industrial Application

TL;DR

This study evaluates debloating tools on a real-world Java application, demonstrating their ability to reduce code size and attack surface, while highlighting limitations in handling dynamic class loading.

Contribution

It provides an empirical assessment of existing debloating tools' effectiveness and limitations on a commercial Java application for security hardening.

Findings

Tools identified significant redundant code that could be safely removed.

Redundant classes included previously vulnerable code, aiding security hardening.

Tools struggled with dynamic class loading mechanisms.

Abstract

Software reuse may result in software bloat when significant portions of application dependencies are effectively unused. Several tools exist to remove unused (byte)code from an application or its dependencies, thus producing smaller artifacts and, potentially, reducing the overall attack surface. In this paper we evaluate the ability of three debloating tools to distinguish which dependency classes are necessary for an application to function correctly from those that could be safely removed. To do so, we conduct a case study on a real-world commercial Java application. Our study shows that the tools we used were able to correctly identify a considerable amount of redundant code, which could be removed without altering the results of the existing application tests. One of the redundant classes turned out to be (formerly) vulnerable, confirming that this technique has the potential to be applied for hardening purposes. However, by manually reviewing the results of our experiments, we observed that none of the tools can handle a widely used default mechanism for dynamic class loading.