fbpx

Concerning the log4j vulnerability (CVE-2021-44228)

log4j logo

TL;DR

Sassafras AllSight, LabSight, and KeySight are safe from CVE-2021-44228, the log4j vulnerability. No mitigation steps are required.

Summary

Recently a new critical vulnerability (CVE-2021-44228) in a common web package has been identified by security researchers. A bug in the popular “log4j” Java library has caused a widespread security risk that is immediate and potentially severe. Since log4j is typically used on Web servers and within Web applications, we have received numerous inquiries from our customers about whether this vulnerability affects the Web UI component of AllSight, LabSight, and KeySight. The short answer is “no”, so if you are still busy chasing down information on other software packages, you can stop reading now and be assured that, at least with KeyServer Platform services, you are safe from this vulnerability and have no need to take any mitigation steps.

Details — Why is this not a problem?

Specifically, none of our products use the log4j package in any way. While log4j is a flexible and useful tool for managing log output, we do not have the need for such functionality. If and when we do find that log management is required, we would not be able to use log4j effectively since our software is not written in the Java language.

To be clear, we do not use log4j simply because we don’t need it, not because log4j is flawed or inherently insecure. All software has bugs and potential security holes, and this time it happens that log4j is the source of those holes. While our sympathy goes out to the system admins who have to find and patch all their services that are affected by this bug, we also empathize with the developers of log4j, and acknowledge their extremely fast reaction to this bug.

More generally, we avoid using third-party libraries in our software. While this approach requires more development time on our part, and comes with its own risks, it means that we have much better knowledge of and control over the source code. We use third party libraries in a few rare cases when they provide specific functionality without excessive additional (unused) features. Furthermore, we only use libraries for which we have access to the source code so we have the ability to tune performance and fix bugs ourselves without relying on outside developers.

Of course all of our software runs on and uses the native services of a host Operating System. Responsibility for maintaining security of the OS falls upon the system administrator, and we make the typical recommendation that all the latest security patches and mitigations are applied, especially on the host running our server components.

Finally, as mentioned previously, all software has bugs and our software is no exception. We make every effort to find and fix bugs both during testing and after a new version is released. You can view our Secure Coding Practices for a summary of our approach to writing software.

What about Sassafras’s own web site and web-facing services?

Sassafras operates three basic web-facing servers: Our main website at www.sassafras.com, our Product Recognition Service (PRS), and a collection of internal development servers.

Main Website

Our main website runs on the Apache web server, and is developed using the WordPress platform. WordPress has its own history, but for the current situation our specific instance is not susceptible to exploitation. This server does not have log4j installed, and in fact does not run any Java-based services.

Product Recognition Service

PRS runs on our own web server code, which is the same code used by the web service built into AllSight, LabSight, and KeySight. As with our main products, PRS does not use log4j (or Java) in any way.

Internal servers

Certain of our internal servers are web-accessible to facilitate remote work. These servers sit behind a reverse proxy for security reasons. Only one of these servers, an identity server that we use for compatibiilty testing, uses log4j, and it has been patched to avoid the new vulnerability. Our analysis of the logs for this server show that, while there were a few probes for CVE-2021-44228, none made it through the proxy. The remaining web-accessible services do not use log4j (or Java), and are access controlled.

Our build servers — those systems that compile and create the software that we ship to customers — do not run web services of any kind. Access to these systems is available only in our physical office or via restrictive VPN connection.

Author:
Head codemonkey at Sassafras, Mark enjoys hiking during Summer in New Hampshire and Vermont, and during the other Summer in New Zealand. The rest of the time he spends writing bugs and trying to fix them.

Get started

If you want to get a free consultation without any obligations, fill in the form below and we'll get in touch with you.

Live Demo

  • Sassafras will not share your personal information, period. We take privacy seriously. You may opt out of our communications at any time.