A Friday (10 Dec 21) headline in Wired magazine reads ‘The Internet Is on Fire‘. That got a lot of attention and drove me to researching the log4j vulnerability, as it is called.
The Damage
The situation is bad, very bad, but the computer network is probably not in quite as dire straits as the attention-getting headlines and news items imply.
The defect is in a popular open-source library that is used in enterprise applications, the computer programs that support large businesses and government agencies. Log4j is one of the most frequently downloaded open-source modules. The module has even migrated off-planet and is running on Mars. A patched version was posted 10 Dec 21 and was already downloaded over 630,000 times four days later. The vulnerability clearly has the development community’s attention.
The defect is also easy to exploit. I daresay that an experienced enterprise developer could code up a successful exploit in less than an hour. Just messing a system up might only take minutes. The first exploits in the wild were on gaming platforms, no doubt by script kiddies.
The ease of attack and seriousness of the compromise have sent hackers on a mad hunt over the network, seeking vulnerable systems.
Home Computers
In general, home computer users should not worry.
The vulnerability may affect individuals, most likely because a remote commercial service an individual uses was attacked or a work-related application was damaged. All an individual can do is wait for the pros to fix the issues. But these issues are on network servers, not home computers.
An attack on a home computer is possible, but not likely. The vulnerability can only affect home computers that have Java (plain Java, not Java Script) installed. A few user level programs require Java installed, but the vast majority don’t. If you have Java installed, you are probably savvy enough to realize you have it because installing and keeping Java updated is usually annoying. Check your installed Java programs for the log4j modules or uninstall Java and forgo some applications until the fire is out.
The fix will be to the application, rather than the Java installation. Be sure to have auto-update turned on to get fixes as they are developed. If you don’t know how to check module dependencies, contact me in the comments. Enterprise scripts that check for log4j are difficult to write, but spotting log4j on a home system is much easier. Although it’s not hard, it’s too technical to discuss here. If you are a Java programmer, you probably would not have much trouble creating your own patch from the publicly available patched log4j.
Some damage will certainly occur, but, after all those downloads of the patched version, the vulnerability is already much harder to exploit today than it was last Thursday before it was reported. As fixes go, this one is fairly easy and quick, which will turn the vulnerability into history soon, although the ubiquity of the module in enterprise system means a lot of work will have to be done quickly.
How the Vulnerability Works
Log4j is a logging utility. All serious computer programs use some form of logging to record what the program does while it is running. I’ve looked over the programmer’s manual for log4j and some code examples. It’s a nice package: powerful, efficient, and looks easy to work with. A little too powerful for its own good, but I can see why it’s used everywhere.
Enterprise applications are usually widely distributed these days, which means they are made of many separate programs running on different computers distributed through an organization. In addition, most enterprise applications communicate with many other applications in the enterprise and some outside the enterprise.
An example of the power of these complex systems is Amazon’s success in selling such a wide range of products to so many people using so many different warehouses and shipping methods. Keeping all the accounts straight and delivering as predicted most of the time while facing pandemic supply chain disruption is a gargantuan task that requires a huge number of interrelated programs running on millions of networked computers.
When a system like Amazon’s malfunctions, the costs become millions in minutes.
These systems are extremely complex and can be devilish to keep running properly. Large systems change constantly. Equipment is added and replaced. Software added, upgraded, or replaced. Network configurations change as facilities go on and offline. There is no “if ain’t broke, don’t fix it” because everything breaks that is not fixed before the next change breaks it.
One way of managing system-breaking change is to place a sort of map of the system in various places and design applications to consult the map to determine how they should connect with other applications. When a change occurs, the maps are updated, perhaps automatically, and the rest of the system changes to accommodate the change, making the system more resilient and reliable.
Unfortunately, this can also be dangerous. A log that can report the real-time configuration of the system makes proactive reconfiguration and troubleshooting much easier. The log4j developers added this in 2013. But if hackers can get a finger into the map mechanism, they can do great damage.
The log4j vulnerability implements a powerful feature, but it also opened a wide-open door to hacking. I can easily imagine excited and giddy log4j developers neglecting to consider the dangerous consequences of their neat feature. I won’t go into the details of the mechanism, but the vulnerability can trick applications into importing malicious code from a bogus server controlled by hackers instead of a legitimate repository. When executed, bogus code can eventually hand control to the hackers.
The Fix
Fixes are available. The 10 Dec patched version of log4j ends the problem. A change to the configuration of log4j will also fix it, although the reconfigured old version of log4j probably does not work as well as the patched version. A quick change to network firewalls can block the problem also, although not all network firewalls have the capability. Unfortunately, deep packet inspection firewall rules that will stop the log4j vulnerability have a reputation for compromising performance. However, short term instant fixes are often a godsend in crises like this one.
The Prognosis
As I said beginning this post, the log4j vulnerability is bad. However, I am heartened by the vigor of the reaction in the development community. The problem was found, reported promptly, and fixes generated in days, not weeks or months. The industry is maturing and becoming more responsible.