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

When researchers find vulnerabilities that leave older systems exposed, should the software giant create patches or encourage upgrades? Experts weigh in.

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 companys 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 its 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.
Theres no reason or excuse to ship known-vulnerable software, he continues. If youre 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 wont issue a patch because the flaw is deeply ingrained in the way SMB works and many components rely on its behavior.
Microsofts 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 Tripwires 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 doesnt 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.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps