Source: Shutterstock
Another year, another cybersecurity incident. The Log4j zero-day exploits like Log4Shell were made apparent last month and have highlighted several issues in many organizations’ IT stacks over and above updating and patching policies that don’t cut the mustard. At a fundamental level, it’s becoming apparent that there is a growing realization of quite how much more of today’s software depends on open-source code.
The security issues surround the ability of the logging library (common to many applications) to call remote services (LDAP appears to be most common) and execute downloaded Java payloads. In particular, on Windows servers, code can run with full privileges, essentially pwning entire systems.
Even on the relatively more secure Linux platforms, code can be run as a relatively privileged user such as www-data. Log4Shell, as it’s becoming known, continues to evolve, with the Apache Software Foundation (the authors of the library) at the time of writing releasing details of a third security advisory and a new round of patches.
It’s worth noting that running proof-of-concept exploits on systems doesn’t necessarily mean that there hasn’t been a security breach already: many hackers will gain control and then patch to the latest Log4j version to prevent others from usurping them as system controllers. It’s important, therefore, to carefully audit all systems, and given the ubiquity of Log4j, there aren’t many areas of the IT stack that wouldn’t benefit from some careful analysis.
Free as in beer
At a deeper level, the prevalent issue is the use of free and open-source code in software where the interpretation of “free” is lax, whether by accident or design. Sure, FOSS (free and open-source software) code comes with no upfront price, but “free” should be read as free-to-distribute by default (although the details of the myriad of FOSS license agreements will vary), not free of cost.
In most cases, the inference of free to use is easy to make, and therein lies the problem. If no one maintains a library (or application, framework, code snippet, or whatever) that everyone uses, then security holes, bugs, and errors will be commensurate with the number of times that code is deployed.
Many critical libraries and applications are not actively maintained and were often developed in coders’ spare time as a project that would, to use the vernacular, scratch a particular itch. Developers have bills to pay and families to support, and if no one is willing to pay them for their work, they tend to move onto projects that will cover the mortgage.
It’s incumbent on any organization using open-source resources to pay upstream into the projects whose code they use. If every company hit by Log4Shell exploits over the last two months had paid $1 per month to the Apache Software Foundation, the Log4j developers could have both covered their bills and evolved the code so that it didn’t create the havoc it has.
Internal software audits need to go deeper than totting up the numbers of Adobe or Oracle licenses that need to be paid for annually. How many companies running NGINX or Apache code on web servers actually pay upstream to keep the essential updates flowing? Very few in all likelihood, and certainly not enough. Fewer still catalog each of their running applications’ libraries and code elements, and contribute to each, or even some of the projects behind each constituent part.
Users of “free” code need to contribute: monetarily, with code, or however they can – bug reports, documentation, translations, or cold hard cash. Until that happens, we can expect many more of the same cause of vulnerabilities.
6 March 2024