Can one protect from the Log4j exp by sanitizing the parameters?

Question

A zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) was made public on December 9, 2021 that results in remote code execution (RCE). (From an email CloudFlare sent to users)

Is a site susceptible to the Log4J exploit if all parameters taken from the request are sanitized? The most "lenient" form of sanitization on the site removes everything but the alphabet, numerals and punctuation such as hyphen, commas etc.

    int param = SecurityIssues.StringToInt(request.getParameter("param")); 
    String itemType = SecurityIssues.StringToAlphaNumeric(request.getParameter("itemType"));
    String message= SecurityIssues.StringToAlphaNumericPlusPunctuationStr(request.getParameter("message")); 

As it happens the site has other levels of protection (e.g CloudFlare WAF) - and I know that all libraries should be updated. I am just asking whether sanitizing by itself would theoretically provide sufficient protection.

From Steffen Ullrich's answer to How can the Log4Shell exploit affect an end user? it appears that the exploit can only affect information emanating from untrusted sources, and so if all information taken from the request is sanitized then there should be no problem, but I wanted to check that this was correct and that my level of sanitization is sufficient.

Answer 1

Client-side sanitization?

Sanitizing parameters is important, but the challenge associated with this particular vulnerability is that it can be exploited using parameters that are not typically validated. For example, many servers will log the User-Agent header because they want to record the different browsers that are being used. And this is only one example of many. Any request header, query string parameter, or the body of the request could be used to attempt to exploit the vulnerability.

TLDR; Don't trust your web client to sanitize the inputs to your server.

Server-side sanitization?

Will this work? Maybe. If you sanitize literally everything. The server-side preprocessing of your log content would need to be bullet-proof, and there are a number of creative ways that this can be exploited that might fool any regex-based rules that you might use.

${::-j}${::-n}${::-d}${::-i}

For more details, see: https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

WAF

You may have better luck with a Web Application Firewall (WAF) to reduce the risk of such strings being passed to your server, though WAF rules will only reduce the probability of such exploits (they cannot guarantee to catch everything). In this case, any request identified as a potential attack associated with this vulnerability would be rejected and never reach your server.

If you take such an approach, you are deciding that you don't want to try to process requests from attackers safely, but that you don't want to process them at all.

For example, if you are using AWS, you can enable the AWSManagedRulesKnownBadInputsRuleSet with the Log4JRCE rule to block suspicious requests.

https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/

(Many other WAF service providers have similar rules at this point.)

Remediate rather than mitigate

Of course, the best solution is to upgrade log4j to a non-vulnerable version (2.17 at this moment). In many cases this will be less effort than mitigating through sanitization.