As we all know Log4j is a ubiquitous piece of software used to record activities in a wide range of systems found in consumer facing products and services. The discovery of the recent vulnerability in the Java logging package (CVE-2021-4428) This risk posed a severe threat to millions of consumer products from enterprise software to web applications. It presents risk of loss, or breach of personal information, financial loss and irreversible reputation harm. Currently, the FTC is taking action to require organizations to settle any associated risk caused by the known vulnerabilities. The FTC is now noted as using its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposures.
A recent example of this negligence came on the back of a complaint in regards to Equifax’s failure to patch a known vulnerability which irreversibly exposed the personal identifiable information of 147 million consumers. This resulted in Equifax paying $700 million to settle the actions taken by the FTC and the consumer financial protection bureau. The risk for businesses is therefore clear, take actionable steps to remediate the vulnerability, or face litigation, breach risk and reputation damage.
In this guide, we will walk you through how you can use Method Call Removal to mitigate this vulnerability.
Method Call Removal
Method Call Removal has been available since our DashO 6.11 release. It is mostly used for removing logging statements, but it can be used to strip any method calls we’d prefer not to have in our production release. The only caveat is that the method definition must also be in DashO’s input.
Let’s assume Log4j is used for our application’s logging. We might want to remove all log statements from production builds, then create special debug builds with logging enabled as needed. Or, we might want to remove Info, Warn, and Debug messages, but retain Error or Fatal message in our production build. This can be done using DashO’s Method Call Removal feature, without needing to adjust the Log4j configuration.
Please consider the following example:
This application logs informational messages when the app starts, and when it shuts down.
The Log4J configuration has been organized into a global logging class:
In our DashO project, I’ll select the “LogInfo” method for method call removal:
After doing so, the application runs normally, but informational messages are no longer logged to console or written to log file.
After the app has been in production, I may need to create an obfuscated debug build for troubleshooting an issue with a specific client. If so, I can run DashO without Method Call Removal to preserve logging calls in my debug build.
The above example can be downloaded here.
If you have any feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.