The last year has seen the appearance of software issues affecting extremely popular operating systems and software libraries.
Problems with potentially devastating effects, often classified as remotely exploitable. This condition indicates how an attacker can take advantage of these shortcomings without necessarily being physically close to the system, but rather only having visibility of it from the network or logic.
In this article I try to better clarify some important differences between specific terms, too often used interchangeably (and improperly) with the aim of causing a stir or grabbing clicks on the Internet.
Let's start with a couple of absolute truths that I find important to remember.
The first is a quote from CyberSecurity luminary Gene Spafford: “The only truly safe system is the one that is turned off, disconnected, locked in a titanium cage, in a concrete bunker full of nerve gas and guarded by very well-paid armed guards. Even then, I wouldn't bet my life on it."
The second truth, decidedly simpler to state, reiterates more simply that “no software is perfect”.
Define these starting points, let's try to clarify the important difference between a bugs, a vulnerability and a exploit; ending with clarifying the importance of the conditions necessary to be able to take advantage of these elements.
Far removed from the world of entomology from which the term originates, the bugs o Bacchus of software can be defined as a code imperfection due to a code error made during development. This error occurs only when certain conditions are met.
Curiosity known not to everyone and definitely to those who persist in calling this an error hole software is the genesis of this term in the IT field: it derives in fact from the times when software was encoded on punched cards and computers were enormous cabinets often in the basement of a building; in these metal cabinets the various components were anything but miniaturized and the space allowed - in certain conditions - the proliferation of small animals that could feed on punched cards like a caterpillar would feed on a crunchy ripe apple. It was precisely in these contexts that the expression was born software bug which has remained undaunted for over half a century in color (and a little nerd) world of developers.
So that from a bugs However, if a vulnerability is generated, some important conditions must exist.
The first is that the sequence of events that leads to the bugs to show itself to the world, generating the harmful effects of the mistake initially made by the developer. Not only is it profoundly wrong to use the term bugs and vulnerability interchangeably, but even a bugs known is not synonymous with vulnerability.
To better understand this nuance, let's try to examine how a vulnerability is reported - taking inspiration from the American threat analysis organization MITER. Among MITER's countless activities there is in fact the management and updating of a vulnerability database called CVE (Common Vulnerabilities and Exposures).
Below is an example of how a vulnerability is represented to the general public:
It immediately becomes clear that the description of the context tells much more than the possible ways of exploiting the bug without however giving examples on the as in practice: for example, it informs us that the Omada ER605 model from the manufacturer TP-Link has a buffer overflow problem: this means that due to a development error the device's memory accepts more data than it could contain; tells us that it is not necessary to be authenticated to write to this memory; highlights to us how the exploitation of this crack can also take place remotely, with the qualification of Remote Code Execution.
The vulnerability report never says how to exploit it, for several valid reasons.
First of all, if it did so it would put at risk those who have not yet had time to remedy the situation, if it were possible for example with the application of a software update from the manufacturer or a patch.
Secondly, the task making a vulnerability exploitable is the responsibility of the writer exploit.
THEexploit represents a code and/or a procedure that if executed causes the error that exploits the bugs left in the developer's code.
In summary: bugs, vulnerability ed exploit they are three separate entities, if anything consequent but certainly not synonymous.
The practice of analyzing the characteristics of the vulnerabilities, the remediation procedures, the possible availability of one patch by the manufacturer constitutes a process part of every company's cybersecurity measures - called Vulnerability Management and it is one of the most challenging objectives of a good corporate cybersecurity policy.
