A faulty Microsoft Windows security update not only didn’t fix the bug in VBScript, it opened another way for hackers to access a computer.

Patching software is a complex thing, but this blunder is unforgivably bad and the delays make it even worse.  It undermines confidence in Microsoft security testing and their willingness to fully disclose facts to their paying customers.

It all started when researchers at Qihoo 360 reported to Microsoft a bug in the Windows Scripting Engine for Windows 7, 8 and 10 plus server releases. The security bug could be used in a web page or Office document to gain access to the computer.  The use-after-free() problem was being used by hackers ‘in the wild’ to get into computers.

Not only did Qihoo 360 report the bug, they also included an example ‘proof of concept’ code to show how the bug could be exploited.

In May 2018 Microsoft released a patch for the bug now known as CVE-2018-8174. That would have been great IF Microsoft had fixed their operating system properly.  But they didn’t.

Qihoo 360 didn’t take Microsoft’s Word about the patch and tested it themselves.

“… we realized that the fix was not so complete and there still exists similar problems which could be leveraged to achieve reliable remote code execution in VBScript engine,” said Yuki Chen from Qihoo 360.

Microsoft did an incomplete fix.  They patched the bug from the sample ‘proof of concept’ code but not the deeper bug in the VBScript engine.  The software equivalent of a Band-Aid over a wound.

Take a bug, leave a bug

Not only did Microsoft not do a proper job, the faulty update added another security hole into Windows … like there aren’t enough already.

The new Windows bug was also disclosed to Microsoft and became known as CVE-2018-8242 which reads like it’s the same as the earlier bug but it’s not.

Microsoft introduced a ‘double free’ security hole into Windows with the May patch.

July fixes the problems

It’s only with this month’s round of security patches that the whole thing has been fixed … fingers crossed.

The original VBScript /  use-after-free() bug has been properly closed

And the Microsoft induced ‘double free’ error is also a thing of the past.

Of course, you’ll find no mention of this on the Microsoft site.  The whole story is told by Yuki Chen at Qihoo here. If you have trouble accessing that page, like we did, try the webcache.

Why it matters

These aren’t small nerdy issues.  Microsoft left a known and ‘in the wild’ security hole in Windows for over two months.

Redmond tried a quick fix instead of doing a proper job.  Taking a ‘shortcut’ made things worse both by leaving the security bug largely in place and also adding another potential hacking opportunity.

Maybe the ‘softies were under pressure to do the buggy May 2018 patch?  That doesn’t explain why it took external testing to find Microsoft’s lapse and then two months before Windows customers got a proper patch.

Déjà vu all over again

Hasty and incomplete fixes have happened before at Microsoft, this is just the latest known example.

Way back in 1998 there was a calculation bug in Excel 97 with the main example showing how a worksheet could easily not add up a column of numbers.

After public pressure from (modesty forbids) a certain email newsletter, Microsoft produced a patch.  Only to be embarrassed all over again when it quickly became apparent that the patch only fixed the bug for adding up columns leaving the same bug in place for rows.  Oh dear.