Microsoft Reveals Which Bugs It Won’t Patch

Microsoft has put out initial clarification around which bugs it will rapidly patch, and which ones must wait for a new product release – and which ones it won’t address at all.

In a draft document posted online on Tuesday, the software giant laid out the criteria that the Microsoft Security Response Center (MSRC) uses when deciding what to patch and when.

There are two litmus tests that broadly guide these decisions, as the company explained in the document: “Does the vulnerability violate a promise made by a security boundary or a security feature that Microsoft has committed to defending?”; and secondly, “does the severity of the vulnerability [as determined by Microsoft’s five-tier rating system] meet the bar for servicing?”

The “bar for servicing” in Microsoft parlance means that the flaw is rated Critical (i.e., allowing for remote code execution) or Important (privilege escalation, information disclosure, security bypasses and RCE), according to the document details.

If the answer to both questions is yes, then the prescribed action is to issue a patch, either on Patch Tuesday or, in rare cases, in an out-of-band release; if the answer to either question is no, then the bug is relegated to back-burner status in most cases, with a fix coming in a subsequent release of the product or service.

Exceptions could be possible though; if a flaw has a severity level of Moderate, but applies to a security boundary or security feature that has a servicing commitment, then a patch could conceivably still be issued.

Researchers welcomed the transparency. “The only negative here is that by telling people what you won’t fix, you open yourself to bugs in those areas,” said Brian Gorenc, director of vulnerability research for Trend Micro, in an email interview with Threatpost. “Of course, there’s a reason Microsoft has chosen not to fix those bugs. It’s incredibly unlikely those bugs would be impactful to the end user.”

Security Boundaries and Features

In the draft, Microsoft lists eight security boundaries and nine security features that carry promises for servicing, all of which are part of the company’s bug-bounty program.

As for the boundaries, Microsoft lists AppContainer sandbox, kernel, network, process, session, virtual machine, Virtual Secure Mode and web browser boundaries as qualifying. The company defines a boundary as “a logical separation between the code and data of security domains with different levels of trust,” such as the separation seen between kernel and user mode.

On the security features front, the qualifying items are authentication protocols, BitLocker and Secure Boot, Host Guardian Service, platform cryptography, Windows Defender Application Control, Windows Defender System Guard, Windows Hello and Windows Resource Access Control. Some bypasses are out-of-scope, however, depending on the details of the flaw.

Microsoft added a caveat here for defense-in-depth security features that “may have by-design limitations that prevent them from making a promise,” even though some of those listed in the document are part of the bug-bounty program.

In these instances, Microsoft contends, a bypass “can’t pose a direct risk because an attacker must also have found a vulnerability that affects a security boundary, or they must rely on social engineering to achieve the initial stage of a device compromise.” Gorenc pointed out the example of User Account Control (UAC).

“The user experience makes it feel like a security boundary, but from a technical perspective it really isn’t and therefore won’t get serviced as a security bug,” he told Threatpost.

Researchers Weigh In

The document is just a draft for now – Microsoft is asking for feedback from the research community before publishing a final version.

“We understand that researchers have wanted better clarity around the security features, boundaries and mitigations which exist in Windows and the servicing commitments which come with them,” Microsoft said in a short post online.

The security community has welcomed the development.

“In order to facilitate the discussion, Microsoft is marking their document,” explained Qualys director of product management Jimmy Graham, speaking to Threatpost. “This allows security researchers to provide comments on the current draft and offer recommended suggestions for potential changes. Microsoft is handling this type of conversation in a great way, with complete transparency.”

The prioritization makes sense, according to Brian Contos, CISO at Verodin.

“In a perfect world Microsoft would find a bug and patch a bug and the story is over,” he told Threatpost. “Unfortunately, the reality is that not all bugs are created equal, and some patches require a greater investment in time and resources to mitigate. Also, Microsoft (and any software company) has to concern themselves with not just patching a bug and ensuring the patch works, but they must also make sure the patch does not create new issues with their code or with other software, including software created by other organizations that integrates with their code.”

READ MORE HERE