Third-Party Windows Updates Kind of Risky, Security Expert Says

[CrAKeN]

 

Microsoft expected to patch the flaw on March 14

 

Google disclosed two different unpatched Windows vulnerabilities, one of which recently has received a third-party fix from a company called 0patch, whose purpose is to keep users secure until Microsoft itself releases an official update.

 

With the next Patch Tuesday taking place on March 14, there’s no doubt that there are plenty of consumers and IT admins out there who are tempted to deploy this unofficial patch, especially because Google went public with vulnerability details, so Windows users are more or less exposed to attacks.

 

To determine whether users should turn to third-party patches for Windows flaws or not, we reached out to Chris Goettl, product manager at Ivanti, who told us that it’s better for everyone to turn to the existing mitigation options than to deploy such fixes.

 

Better stick with existing workarounds

 

Chris explained that in the case of discontinued products or open-source solutions, third-party patches are super-useful, but this is not the case with software that’s actively supported by their vendors, as it’s happening with Windows.

 

“The problem starts to come in when dealing with software especially where there may be warranties or EULAs involved.  If something were to go wrong and the versions of files are unexpected, Microsoft will be resistant to supporting the system until it is reverted back to production files,” he told us.

 

“Many 3rd parties consume and modify Microsoft components, but in doing so they assume support for those files. Once Microsoft releases a fix will it install over the top of the changes from 0Patch? If any issues occur it leaves the user\company in a gray area.”

 

Chris goes on to explain that sticking with the existing workarounds, such as blocking outbound SMB connections (TCP ports 139 and 445 and UDP ports 137 and 138) from the local network to the WAN, until a fix is provided, which should happen on March 14.

 

We’ve also reached out to Microsoft for some comments on these third-party patches, but the company instead provided us with a link to the blog post announcing the delay of February 2017 Patch Tuesday with no further statements provided regarding the risks of installing unofficial fixes.

 

Source

[straycat19]

0patch released a patch for the gdi32.dll vulnerability.  The amazing thing about this is Microsoft has been trying to patch/secure gdi32.dll since the release of Windows 95 and hasn't been able to do it yet, obviously.  Which means this isn't going to be the last vulnerability in that particular dll.

 

9 hours ago, CrAKeN said:

Chris goes on to explain that sticking with the existing workarounds, such as blocking outbound SMB connections (TCP ports 139 and 445 and UDP ports 137 and 138) from the local network to the WAN, until a fix is provided, which should happen on March 14.

 

The odd thing about this recommendation is that these are the same ports that we started blocking in 1999 as a result of the Blaster Worm and other malware that was around at the time and we have never stopped blocking them.  Any organization that was in existence at that time should have blocked those ports also and should not be susceptible to this vulnerability.  And though I can't see any security conscious organization unblocking a port that was a known point of infection, I am sure there exists many organizations, who in the years since 1999, had a change in security personnel and without prior knowledge or notes would have unblocked them.