Log4Shell Security Flaw Teaches Lessons About Open Source Contribution

Another year, another cybersecurity incident. Log4j zero-day exploits such as Log4Shell were highlighted last month and highlighted several issues in the IT stacks of many organizations beyond update and patch policies that don’t cut the mustard. . At a fundamental level, it is becoming evident that there is a growing realization of how much software today depends on open source code.

Security concerns relate to the ability of the logging library (common to many applications) to call remote services (LDAP seems to be the most common) and run downloaded Java payloads. In particular, on Windows servers, code can run with full privileges, mostly on entire systems.

Even on relatively more secure Linux platforms, code can be executed as a relatively privileged user such as www-data. Log4Shell, as it is called, continues to evolve, with the Apache Software Foundation (the authors of the library) at the time of writing to release details of a third security advisory and a new round of security advisories. fixes.

It should be noted that performing proof of concept exploits on systems does not necessarily mean that there has not been a security breach already: many hackers will take control and then apply the latest version. of Log4j to prevent others from spoofing them as a system. controllers. So it’s important to audit all systems carefully, and given the ubiquity of Log4j, there aren’t many areas on the IT stack that wouldn’t benefit from careful analysis.

Free as in beer

At a deeper level, the predominant problem is the use of free and open source code in software where the interpretation of “free” is lax, whether by accident or by design. Of course, the FOSS code (free and open-source software) is not offered in advance, but “free” should be read as free to distribute by default (although the details of the myriad of FOSS license agreements will vary), not for free.

In most cases, free-to-use inference is easy to do, and that’s where the problem lies. If no one maintains a library (or an application, framework, snippet, or whatever) that everyone uses, then security vulnerabilities, bugs, and errors will be proportional to the number of times that code is deployed.

Many critical libraries and applications are not actively maintained and have often been developed during coders’ spare time as a project that, to use the vernacular, would 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 embark on projects that will cover the mortgage.

Any organization using open source resources is responsible for paying upfront for projects whose code they use. If every company impacted by Log4Shell’s exploits over the past two months had paid Apache Software Foundation $ 1 per month, the developers of Log4j could have both covered their bills and scaled up the code so that it didn’t create the havoc it has.

Internal software audits must go beyond the total number of Adobe or Oracle licenses that must be paid for each year. How many companies running NGINX or Apache code on web servers are actually paying upfront to keep essential updates flowing? Very little in all likelihood, and certainly not enough. Even fewer catalog each of the libraries and code pieces of their running applications, and contribute to each, or even some of the projects behind each constituent part.

Users of “free” code should contribute: financially, with code, or as they can: bug reports, documentation, translations, or cash. Until that happens, we can expect a lot more from the same cause of vulnerabilities.

About Jon Moses

Check Also

Intel promises “substantial contributions” to the growth of RISC-V • The Register

Analysis Here’s something that would have seemed odd just a few years ago: to help …