Microsoft Advisories Are Getting Worse

A predictable patch cadence is nice, but the software giant can do more.

Jacob Baines, Lead Vulnerability Researcher, VulnCheck

May 15, 2023

6 Min Read
Tiles showing padlocks. One is red, indicating a vulnerability.
Source: Andrii Yalanskyi via Alamy Stock Photo

As the 20th anniversary of Patch Tuesday approaches later this year, many are reflecting on the importance of the program that brought predictability to Microsoft security patch cycles. Patch Tuesday undoubtedly improved the security of customers, and the success of the program is reflected in the number of organizations that established their own Patch Tuesdays, including Adobe, Siemens, Schneider Electric, and more.

However, the quality of the vulnerability details published by Microsoft on Patch Tuesday has noticeably declined. Vulnerability descriptions used to be useful. Now they are reduced to being nearly meaningless. Compare, for example, the CVE descriptions in the National Vulnerability Database (NVD) for CVE-2017-0290 and CVE-2023-21554 (aka QueueJumper):

CVE-2017-0290 NVD Vulnerability Description

The Microsoft Malware Protection Engine running on Microsoft Forefront and Microsoft Defender on Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 does not properly scan a specially crafted file leading to memory corruption, aka "Microsoft Malware Protection Engine Remote Code Execution Vulnerability."

CVE-2023-21554 Vulnerability Description

Microsoft Message Queuing Remote Code Execution Vulnerability

The first description details the affected components (Forefront and Defender), the affected versions (various Windows operating systems), the attack vector (crafted file), and a bug class (memory corruption). The second description lacks almost all of those details.

This is not an isolated case. In fact, Microsoft's CVE descriptions have been on the decline for a number of years. The following graph maps the median length of Microsoft-created CVE descriptions over the past 20 years:

Graphic showing median length of Microsoft CVE description

Impact on Defenders

The poor descriptions have a serious impact on practitioners. It's difficult to prioritize vulnerabilities when it's unclear what the problems are. How is anyone supposed to know if Microsoft Message Queuing Remote Code Execution Vulnerability is a big deal or not? How many practitioners know what Microsoft Message Queuing is, or what major pieces of software use it? Is it enabled by default? Does it listen on a network port? The practitioner is forced to go looking for all this information themselves.

To avoid that type of thing, MITRE created well-defined rules for what is required in a CVE description. These are the minimum requirements:

8.2.1 MUST provide enough information for a reader to have a reasonable understanding of what products are affected.

8.2.3 MUST include one of the following:

1. Vulnerability Type

2. Root Cause

3. Impact

Does Microsoft Message Queuing Remote Code Execution Vulnerability Satisfy These Requirements?

Maybe a very loose interpretation of 8.2.3 would be satisfied with Code Execution Vulnerability. But can anyone reasonably say that "Microsoft Message Queuing" describes the affected products?

At least Microsoft included a specific service for CVE-2023-21554 (Message Queuing). It didn't even do that for CVE-2023-23415. That description doesn't list any software, and instead opts to list an affected protocol:

CVE-2023-23415 Vulnerability Description

Internet Control Message Protocol (ICMP) Remote Code Execution Vulnerability

CWE Assigned to Microsoft CVE

It's unclear why MITRE allows Microsoft to ignore (or, generously, skirt) the CVE description rules. What is clear is that everyone else is worse off because of it. If appealing to the overburdened practitioner isn't enough, we can actually measure the impact of Microsoft's bad CVE descriptions on NIST's per CVE common weakness enumeration (CWE) ID assignment.

For every CVE in NIST's NVD, it attempts to assign a CWE. When the vulnerability contains insufficient information to assign any specific CWE, then NIST assigns NVD-CWE-noinfo. Basically, "this CVE has insufficient details for us to know what the weakness is."

Back in 2015, NIST assigned NVD-CWE-noinfo to only a few Microsoft CVEs. In 2022, the majority of Microsoft CVEs received the NVD-CWE-noinfo designation.

Graphic showing CWE assigned to Microsoft CVE

NIST's effort to assign CWE to each CVE helps with vulnerability prioritization and makes it easier to map vulnerabilities to CAPEC and/or MITRE ATT&CK. NVD CWE are used by a host of downstream projects, including MITRE's own CWE Top 25. Recent Microsoft vulnerabilities are largely excluded from these activities, because Microsoft has chosen to provide insufficient information to even assign a CWE to its vulnerabilities.

Unfortunately, it's not as if the information can be found in the Microsoft advisory itself, either. In fact, practitioners need to refer to outside sources, because Microsoft doesn't keep its advisories up to date. For example, both CVE-2022-41080 and CVE-2019-1388 were added to the Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities Catalog in 2023. Microsoft's NVD entries correctly reflect that. But both Microsoft advisories state that the vulnerabilities haven't been "exploited." That's because its advisories only reflect exploitation at the time of publication.

Microsoft Advisory Exploitability Table for CVE-2019-1388

The result is that Microsoft's advisory is both out of date and lacks information. The NVD entry is up to date, but also lacks information. Thankfully, there are a host of third parties trying to plug the information gap. For example, Zero Day Initiative publishes a rundown of every Patch Tuesday. This is its description of CVE-2023-21554 (aka QueueJumper):

This is a CVSS 9.8 bug and receives Microsoft's highest exploitability rating. It allows a remote, unauthenticated attacker to run their code with elevated privileges on affected servers with the Message Queuing service enabled. This service is disabled by default but is commonly used by many contact center applications. It listens to TCP port 1801 by default, so blocking this at the perimeter would prevent external attacks. However, it's not clear what impact this may have on operations. Your best option is to test and deploy the update.

This description contains important information that the CVE entry does not, such as:

1. Message Queuing is a service.

2. Message Queuing is disabled by default.

3. Message Queuing listens on TCP port 1801.

4. Exploitation may result in elevated privileges.

All of that is incredibly useful for defenders — information that should have appeared in the CVE dictionary and the NVD entry, but doesn't. This is information that belongs in the CVE catalog for context, vulnerability prioritization, and historical safekeeping. Instead, already time-constrained defenders are put at a disadvantage because they're forced to go hunting for third-party descriptions of every Microsoft vulnerability.

About the Author(s)

Jacob Baines

Lead Vulnerability Researcher, VulnCheck

Jacob Baines is the lead vulnerability researcher at VulnCheck. With more than a decade of experience, he's conducted research for a wide array of organizations, including VulnCheck, Rapid7, Tenable, Lockheed Martin, and Dragos. His research focuses on discovering and exploiting initial access vulnerabilities. He's credited with more than 100 CVEs, and has presented his research at Black Hat, DEF CON, Infosecurity Europe, and several BSides events. He's an active member of the open source exploit development community and a contributor to Metasploit.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like

More Insights