Earlier this month, the existence of a critical vulnerability in Apache Log4j 2 was revealed and a PoC for it published. Dubbed Log4Shell, it’s an issue in a logging library for Java applications that is widely used across popular open-source projects and enterprise-grade back-end applications. Log4Shell introduced a critical security risk, scoring 10 out of 10 in severity.
Using open-source software has proven to be one of the most effective responses to this type of risk. While open-source software doesn’t guarantee a life free of vulnerabilities, it does guarantee fast response and remediation, which is crucial in the event of a large-scale security risk such as that brought on by Log4Shell.
Benefits of open source
Open-source software is defined as “software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose.” Some of the benefits of this are lower hardware costs, higher-quality software, flexibility, security, and transparency.
Having access to the source code and permission to alter it means that anyone can submit to the creator or maintainer desired changes to be included in the upstream software. While it also means that malicious actors can explore the code and probe it for vulnerabilities, those people already do this with closed-source software using techniques like fuzzing.
Closed-source software is not inherently safer that open-source software.
When a software’s source code is not made available for inspection, only the vendor can implement fixes, and this creates disparity between attackers and defenders (i.e., more attackers, fewer defenders.) That gap is flipped for open-source software, with more defenders than attackers. Additionally, closed-source software is more likely to have exploitable (or actively exploited) vulnerabilities in the wild for a longer time and will have a lengthier mean time to repair (MTTR) for those vulnerabilities. Companies are also less likely to publicly report vulnerabilities in their closed-source software due to image and liability concerns, while open-source software is built on a model of transparency and openness.
In the case of the Log4j 2 vulnerability, its open-source status meant that once it was discovered, the entire community of developers could work on fixing it and also perform code reviews that uncovered two additional vulnerabilities (as of December 20, 2021).
Mitigating Log4Shell
The vulnerability makes it possible for malicious actors to execute arbitrary code on or retrieve confidential information from the system being attacked. There are two ways to mitigate a vulnerability like this: by patching or updating Log4j in all systems and applications where it’s deployed, or by blocking malicious requests as they enter the network, often through a reverse proxy or load balancer.
In the hours and days following the disclosure, many developers and companies published free detection and mitigation features, including container image scanning utilities and network plugins to detect and block the Log4Shell exploit before it reaches a vulnerable backend server. The influx of energy and defensive response showcases the true power of the open-source community.
Credit: Source link
