Log4Shell and Spring4Shell

Last night I slept like a log. I woke up in the fireplace. 
- Tommy Cooper 

When it rains, it pours. These two security vulnerabilities cropped up within a few months of each other and hit the news in a big way. What are the similarities and differences between them, and can we learn anything from what happened? 

Log4j is a Java-based framework used for logging. In December 2021, it was announced that it contained a security vulnerability that allowed arbitrary code execution on affected servers. The vulnerability was named Log4Shell because it could grant the attacker shell login. Apache gave it the CVSS severity rating of 10, the worst possible score, and several experts called it the most critical vulnerability ever. It was estimated to affect hundreds of millions of devices, as well as several popular cloud hosting and cloud service providers. 

At the end of March 2022, the Java-based Spring framework announced a remote code execution vulnerability in certain specific installations, dubbed Spring4Shell because of some similarities with Log4Shell. It was also rated as critical in severity, but as far less systems were vulnerable the scope was thankfully much less, and the ensuing panic died down quickly. 

So besides affecting Java-based software and having similar names, what did these two vulnerabilities have in common? Both affected logging. That is, software used to write system diagnostics information into files on the server. This is of course an important feature used for development, debugging, and statistics. What is it about logging that makes it potentially dangerous, and of interest to attackers and defenders alike? 

At first look, if an attacker can affect what gets written to log files, they can for example prevent logging to hide tracks of their activities. Or they can write false logs to blame someone else. Or simply flood the logs with endless garbage in a (D)DOS attack. This can be bad for those affected, but not catastrophically bad. It doesn’t sound like it would be “the most critical vulnerability ever”. No, what we’re talking about here is more sinister than this. 

What makes logging particularly interesting to an attacker is the simple fact that it involves writing data to files on the server. It has to, it’s the whole point of the feature. Most parts of the system don’t do this. There are two kinds of vulnerabilities: First, the attacker might be able to affect what gets written. This can be used to mislead or flood, as mentioned. If the logs can be viewed by the administrator in a web interface, then injected JavaScript might be interpreted – an XSS attack. Injected PHP scripts might be interpreted if the attacker is able to trick the web server to serve the log file as if it was a PHP file. This is usually harder, but if they can achieve it, it allows remote code execution. 

Second, the attacker might be able to affect which file the data gets written into. This is where things get most critical. By itself you could use this to write log content to a system executable, which would crash the system (DOS attack). But if they can control both the file and the written data, they can write whatever program code they want and have the server execute it. That gives them more or less complete control over the vulnerable system. They could for instance write a program that gives them command-line access: a shell. Hence the name of these vulnerabilities. 

There are a few other parts of a typical web system that write data to files. There is for example caching, and file uploads, and file exports. All of these can and have been affected by remote code execution attacks in various software. It is obvious we must handle file writes with due care. The tried-and-true security advice of filtering input and escaping output will be a good starting point, as well as using reputable dependencies and keeping them up to date. 

Log4Shell did not affect Ibexa DXP directly. There were no reports of exploits targeting Ibexa products or services. This is not surprising, since Ibexa DXP is PHP-based. The DXP uses Java-based search solutions though, Solr or Elasticsearch, and they use Log4j. Therefore, we released a security advisory on CVE-2021-44228, outlining steps to take to upgrade Log4j, Java JDK, Solr or Elasticsearch, or work around the problem if upgrading was not possible. 

Spring4Shell did not affect Ibexa DXP at all. Spring is not used in the DXP, so no advisory was released for it. Some internal Ibexa systems and services may have been affected, and we patched them quickly on our end. There is no known exploit against our services, and we have no reason to suspect any breach. 

Please remember our guidelines for safely reporting security issues in Ibexa products and do the same for other vendors. Thanks for reading, and stay secure!