Martian Vulnerability Chronicles

Well, there should have been an optimistic post about my vulnerability analysis & classification pet-project. Something like “blah-blah-blah the situation is pretty bad, tons of vulnerabilities and it’s not clear which of them can be used by attackers. BUT there is a way how to make it better using trivial automation”. And so on. It seems that it won’t be any time soon. ¯\(ツ)/¯

I’ve spent several weekends on making some code that takes vulnerability description and other related formalized data to “separate the wheat from the chaff”. And what I get doesn’t look like some universal solution at all.

Pretty frustrating, but still an interesting experience and great protection from being charmed by trendy and shiny “predictive prioritization”.

Literally, when you start analyzing this vulnerability-related stuff every your assumption becomes wrong:

• that vulnerability description is good enough to get an idea how the vulnerability can be exploited (let’s discuss it in this post);
• that CVSS characterizes the vulnerability somehow;
• that the links to related objects (read: exploits) can be actually used for prioritization.

Actually, there is no reliable data that can be analyzed, trash is everywhere and everybody lies

Let’s start from the vulnerability description. Great example is the last week critical Linux kernel vulnerability CVE-2019-8912.

> In the Linux kernel through 4.20.11, af_alg_release() in crypto/af_alg.c neglects to set a NULL value for a certain structure member, which leads to a use-after-free in sockfs_setattr.

Wow! I think every human being who read this, if he/she is not a Linux Kernel geek, will have these questions: “And what’s next? It’s something about cryptography (“crypto”) and sockets (” sock…“), but what does this mean exactly for me and my IT infrastructure?”

The links don’t make it clearer. Securityfocus page is empty, and at ozlabs.org there is just some email messages where not a word is about actual exploitation.

Vulnerability Type “Use After Free” also doesn’t give much actionable information.

So, how would you process it automatically, if even the manual analysis is tricky? And what would you do with such vulnerability if you don’t get additional data? Just ignore it? Even if the criticality is high (Base Score: 9.8 CRITICAL for this vulnerability)? Lot’s of questions.

Certainly, there are some standard of vulnerability description and lot’s of them contain the name of the vulnerable application and theissue type (RCE, DoS, Information Disclosure, etc.), that can be analyzed. But pretty huge part of them DON’T. Especially after Mitre gave third-party organizations (93 CNAs!) power to create their own CVE IDs. Technically for many CNAs NVD became became a bug tracker and they add there whatever they like.

So, when some Vulnerability Management vendor will tell you how they use advanced neural network and analyze 150 factors to get the sense from vulnerability description, ask them about CVE-2019-8912.

Next time I am going to write about very different types of RCEs (some them are not really RCEs) and exploits (some of them are also not actually exploits). Stay tuned.