Tag Archives: bug

Exploit accounting in Vulristics: bug and new component name

Leave a reply

Exploit accounting in Vulristics: bug and new component nameExploit accounting in Vulristics: bug and new component name

Exploit accounting in Vulristics: bug and new component name.

🔹 I discovered that sometime in April a bug was added to Vulristics: vulnerabilities without exploits received the value of the corresponding component 0.5, not 0. 🤦‍♂️ Somehow I didn’t pay attention to it and no one reported it to me. I corrected it with today’s commit. I’m going to regenerate the Microsoft Patch Tuesday and Linux Patch Wednesday reports for April and May. This, of course, is not a super-critical bug, but the final vulnerability score was distorted. If you use Vulristics, take note and update.

🔹 At the same time, I renamed the “Public Exploit Exists” component to the more logical “Exploit Exists”. It takes values:
1, if there is a public exploit (link or flag in the BDU)
0, if there is no exploit data at all
from 0 to 1, if there is data about a private exploit/PoC

🔹 I created a Changelog and added the “-v” or “–version” parameters. I have been running a project without versions since 2020. 😅🤷‍♂️

На русском

No left boundary for Vulnerability Detection

5 Replies

No left boundary for Vulnerability Detection. It’s another common problem in nearly all Vulnerability Management products. In the post “What’s wrong with patch-based Vulnerability Management checks?” I wrote about the issues in plugin descriptions, now let’s see what can go wrong with the detection logic.

The problem is that Vulnerability Management vendors, in many cases, have no idea which versions of the Software were actually vulnerable.

OMG?! How this can be true? 🙂 Let’s take an example.

Each vulnerability at some points in time:

  • was implemented in the program code as a result of some mistake (intentional or not)
  • existed in some versions of the program
  • was detected and fixed

Read more about this in “Vulnerability Life Cycle and Vulnerability Disclosures“.

No left boundary in Vulnerability Detection

Let’s suppose that we have some Software A with released versions 1, 2 … 20.

Just before the release of version 10, some programmer made a mistake (bug) in the code and since the version 10 Software A has become critically vulnerable. Before the release of version 20, Software Vendor was informed about this vulnerability and some programmer fixed it in version 20. Then Software Vendor released a security bulletin: “Critical vulnerabilities in the Software A. You are not vulnerable if you have installed the latest version 20.”

And what does Vulnerability Management vendor? This vendor only sees this security bulletin. It is logical for him to decide that all versions of Software A starting from 1 are vulnerable. So, it will mark installed versions 1 … 9 of the Software A as vulnerable, even so actually they are NOT.

Continue reading →

What is a vulnerability and what is not?

2 Replies

What is a vulnerability and what is not? It looks like a pretty simple question. I used it to started my MIPT lecture. But actually the answer is not so obvious. There are lots of formal definitions of a vulnerability. For example in NIST Glossary there are 17 different definitions. The most popular one (used in 13 documents) is:

Vulnerability is a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source
NISTIR 7435 The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems

But I prefer this one, it’s from the glossary as well:

Vulnerability is a bug, flaw, weakness, or exposure of an application, system, device, or service that could lead to a failure of confidentiality, integrity, or availability.

I think the best way to talk about vulnerabilities is to treat them as bugs and errors. Because people deal with such entities more often in a form of software freezes and BSODs. 😉

You probably heard a joke, that a bug can be presented as a feature if it is well-documented and the software developers don’t want to fix it.

Bug, feature and vulnerability

Vulnerability is also a specific bug that can lead to some security issues. Or at least it is declared.

Continue reading →