Last month, the news about a serious vulnerability in the Log4j (also known as Log4Shell) utility raised a huge wave of concern in the IT world. We also received numerous requests from our customers to clarify whether this issue may have any negative impact on DHTMLX components. The short answer is “No”.
But let us provide you with a more detailed explanation to dispel any fears.
Why Log4j Issue Caused so Much Fuss
Provided by Apache, Log4j is used in millions of Java applications for logging error messages. Cybercriminals can take advantage of this vulnerability to remotely execute malicious code on computers using a vulnerable Log4j version.
Initially, the whole issue was limited to the server-side, but later a new attack vector in the Log4j vulnerability was found. It is based on a JavaScript WebSocket. This protocol is widely used in modern web browsers for communication with web apps. It transpired that attackers can use a JavaScript WebSocket to trigger remote code execution locally via the drive-by compromise technique. In other words, users with the unpatched Log4j can potentially trigger the vulnerability by simply browsing a website. Therefore, this discovery greatly broadens the attack surface of the Log4j vulnerability.
How it May Affect DHTMLX Users
In general, our customers have nothing to worry about, as we don’t use either Java or WebSockets in our JavaScript libraries, demo apps, and standalone export modules (for Gantt and Scheduler components). Our components run on the client-side and are not susceptible to this vulnerability. To be convinced of that, you can manually check the text files of our components.
Mac and Linux users should use the following commands:
1) Search by name
- find . -name log4j
2) Search by content
- grep -rin log4j
For those who use Windows OS, it is possible to check the content of disk C for Log4j with the following command:
- findstr /mis “log4j” C:\*
It is also important to point out that Log4j should not be confused with a JavaScript logging library named Log4JS. These tools have similar names but their codebases are completely different. It means that Log4JS has nothing to do with the vulnerability under consideration and front-end developers can safely use it in web projects.
At the same time, some other technologies on the server-side of your project may utilize Log4j. What should one do in such a case? The main recommendation from Apache experts is to update to the latest Log4j version. However, the update won’t resolve the issue, if your software has already been compromised. Therefore, it is advised to follow closely any activity in the environment and take advantage of best practices available on the problem.
Hope that you won’t have to deal with this issue in your projects. Wish you productive and secure coding in 2022.