The Patching Dilemma: Should Microsoft Fix Flaws in Older Tech?

When security researchers unearth flaws in Microsoft systems and software, the company is put in a tough situation: does it create fixes and prolong users' reliance on older software in lieu of upgrading? Or does it leave vulnerabilities unpatched and users exposed?

The company's decision to choose the latter was a topic of conversation at Black Hat USA and DEF CON last month. Researchers presented on security holes Microsoft had declined to patch and instead offered users guidance and workarounds to protect their systems from attack.

Microsoft traditionally does not patch flaws in older tech. In June 2017, for example, FortiGuard Labs reported a WINS Server remote memory corruption vulnerability in Microsoft Windows Server. The flaw existed because a remote memory corruption was triggered when handling malformed WINS packets.

Because the functionality WINS provided was later replaced by DNS, Microsoft urged users to migrate away from WINS instead of patching the hole. A fix "would require a complete overhaul of the code to be considered comprehensive," the company said.

"This one does sort of fall into the 'so old it's not worth patching category,'" says RiskSense senior security analyst Sean Dillon. "But realistically the issue should only take a single developer less than a day to fix.

"There's no reason or excuse to ship known-vulnerable software," he continues. "If you're still shipping the code, someone is using it. Either fix it, or remove it."

Microsoft has created patches for older systems on rare occasions, as we saw in its massive June security update following WannaCry. The release included fixes for Windows XP and Windows Server, in addition to Windows, Office, Skype, Internet Explorer, and Microsoft Edge.

However, sometimes security flaws in modern systems go unaddressed and could potentially put businesses at risk.

This is the case with SMBLoris, a vulnerability in the Server Message Block (SMB) file sharing protocol affecting SMBv1, SMBv2, and SMBv3, as well as the Samba Linux server enabling SMB interoperability with Linux systems. All versions of Windows released since 2000 are vulnerable.

Unauthenticated attackers could use SMBLoris to connect with a remote machine via SMB and instruct it to handle the connection using RAM. Using this foothold, they could open thousands of connections to the same target device, exhaust its RAM, and potentially crash it.

SMBLoris, which Dillon discovered while analyzing the EternalBlue exploit, could let a single machine take down a Windows server, he explains. Microsoft won't issue a patch because the flaw is deeply ingrained in the way SMB works and many components rely on its behavior.

"Microsoft's refusal to patch is not limited to older tech," says Dillon. "SMBLoris is an example of a modern Windows vulnerability, that can be exploited even with all versions of SMB disabled. A productive Windows network will have at least some version of SMB enabled. It is ripe for attack and extortion."

The SMBLoris discovery put Microsoft in a tough position, says Craig Young, computer security researcher for Tripwire's Vulnerability and Exposures Research Team (VERT).

"On the one hand, SMBv1 is an ancient protocol by Internet standards and fixes to this behavior could require a major rewrite with the possibility of breaking legacy applications," he says. "On the other hand, SMBv1 has been enabled by default on Windows up to the latest versions."

The competing interests create "a delicate decision," he says. Ultimately, he believes Microsoft was right to advise disabling SMBv1, an early protocol designed without encryption, signature validation, or other security checks and "should not be used in any modern environment."

Young doesn't believe Microsoft should continue patching legacy systems like Windows XP because it prolongs the use of outdated software. In the case of the June fixes, he says, Microsoft "likely took this step to help customers due to extenuating circumstances as well as to avoid negative publicity in the event of widespread infection."

Security researchers have an obligation to notify vendors like Microsoft when vulnerabilities are discovered, explains SafeBreach security researcher Dor Azouri. If a patch is not created, the affected business' teams need to find a workaround to defend against the flaw.

"The response may vary from passive to active," he says. "A passive reaction would mean monitoring a real use of the exploit and acting only in retrospect to minimize damage. An active approach may include utterly disabling the specific feature or program that has the flow in it."

Of course, he adds, the active approach may not be an option if specific software or features affected are critical to business operations. Vendors' decisions to issue patches vary on a case-by-case basis, as evidenced by the June decision to patch Windows XP after WannaCry.

"Ultimately, while we expect software to have bugs, how vendors deal with them is what sets them apart," says Azouri. "Security validation and evaluation must be a continuous process for all parties involved."

Microsoft declined to comment for this story.