Once again the world of information technology is shocked by the discovery of a vulnerability distributed on a huge amount of computer systems, according to some estimates it would reach 70% of the existing web systems on the internet.
But let's proceed in order, as far as possible ...
On November 24, 2021, security researcher Chen Zhaojun of Alibaba Cloud Security Team has discovered a vulnerability on an Apache java library in use since 2013. The versions affected by the vulnerability are those ranging from 2.0 to 2.15.0-rc1 and within a few days other researchers have discovered new vulnerabilities in even later versions.
Patches and versions chase each other ... at the time of writing a new version of the library has been released, 2.17. It will be interesting to see if this new version will be problem free. We always remember that haste is a bad adviser.
The vulnerability found is of the RCE type, or "remote code execution". This is a vulnerability that allows an attacker to instruct a system to be downloaded and executed malicious code (for the more curious I recommend the article by unit42).
The following software and systems are currently reported as at risk: Apache Struts, Apache Solr, Apache Druid, Apache Flink, ElasticSearch, Flume, Apache Dubbo, Logstash, Kafka, Spring-Boot-starter-log4j2, Cloudflare, iCloud, Minecraft: Java Edition, Steam, Tencent QQ, Twitter. But as it is easy to realize through some simple research on the internet, the products of the main ICT companies that make use of Apache Log4j are many, for example CISCO has published a table that for reasons of space I do not carry, but which you can consult at this link.
The Microsoft world reported its products affected by the vulnerability and provided directions to resolve it. If, on the other hand, you are using Linux systems, you do not think you are safer, in this article you will find information on how understand if you are vulnerable.
One last detail, the level of danger of the vulnerability, universally known as the Common Vulnerability Scoring System (CVSS) attributed to the vulnerability, is equal to 10, the maximum possible. A widely used risk index is also the Kenna Risk Score which, in our case it is equal to 87 out of 100, an exceptionally high value.
Talking about the level of risk allows me to make a final consideration that generally concerns the world of security or the so-called "truths" of the security world. I guess it has happened to everyone to hear that software open source they are more secure than proprietary ones as their code is available to anyone for security analysis. It has happened to me that I have heard it said many times in the course of my life; however, if on the one hand I share the value of the statement, on the other hand I would like to highlight some concepts that perhaps are not clear to everyone:
- A software open source (like any other proprietary software!) cannot be considered problem-free solely and exclusively on the basis of a generic statement of control possibilities.
- Affirm that the software open source they are safer - because of the possibility given to anyone to verify the code - it is dangerous. In fact, most of those who use them (and among these I also put the developers who reuse them in their products) have neither the knowledge to do the necessary checks nor any motivation to do so, indeed.
I know very well that what I am saying will not please many, but this is only the last proof of what I say: Log4j is open source yet it took years to figure out what problems it can cause, Heartbleed being a second example. This is not to say that I am against the use of software open source, but to be against their "wild and indiscriminate" use, without adequate support, as it increases the level of risk!
The last consideration relates to the fact that the discovery came from a "laboratory on the other side of the world" and that now we need to run for cover. And when I say run, I mean just that ...
To learn more: