If at first you, er, make things worse, you’re probably Microsoft: Bug patch needed patching

July 23, 2018 TH Author

A remote code execution vulnerability in the Windows VBScript engine was left open for exploitation for two months after it was supposedly patched.

In fact, the fix made things even worse by introducing another remotely exploitable bug in VBScript.

This is all according to researchers at Qihoo 360, who today claimed a security hole in the scripting engine was only partially resolved in Redmond’s May Patch Tuesday, and was only permanently patched in this month’s batch of fixes.

Designated CVE-2018-8174, the flaw was a use-after-free() vulnerability in the scripting engine that could be exploited by a booby-trapped web page, when opened with Internet Explorer, or a malicious document, when opened by Office, to execute arbitrary devilish code with the current user’s rights.

Qihoo 360 researcher Yuki Chen said the team detected the programming blunder being targeted in the wild to infect victims’ PCs with malware, and reported the issue to Microsoft along with a short proof-of-concept (PoC) exploit. Redmond techies would go on to attempt to patch the bug in the May monthly security release.

“After analyzing the patch for CVE-2018-8174 carefully, 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,” Chen explained this week.

“We reported the issues we found to Microsoft immediately, and Microsoft addressed them with a new fix (CVE-2018-8242) in July 2018 security update.”

As Chen explained, Redmond’s remedy for the bug in May only addressed part of the flaw outlined in the PoC, and the underlying cockup – a SafeArray that can be accessed after being erased – was still present. Additionally, the researcher said, the May patch actually created a fresh remote code execution vulnerability in the engine, a double-free() flaw that can corrupt memory leading to arbitrary code execution.

That second side-effect flaw was also reported to Microsoft, and addressed in the July update. Now, if you have the latest fixes, you should be safe from these two CVEs.

“Now for VBScript operations which will free a SafeArray’s internal buffer (erase, redim), before clearing elements in the array, it will first set the internal SafeArray descriptor to null,” Chen explained.

“After this fix, you will not be able to access (read/write/free) the SafeArray inside the |Class_Terminate| again because the descriptor has already been cleared when the callback is invoked.

“This patch perfectly fixed the new issues we reported.”

A spokesperson for Microsoft was not available for immediate comment.

The situation underscores just how difficult it can be to develop secure and thorough security patches. As much as we at El Reg like to tease Microsoft for its inability to properly close up security holes, we understand that writing secure non-trivial code is difficult, and even when problems are clearly identified, they’re not easy to completely fix.

Just ask Intel. ®

Sponsored: Following Bottomline’s journey to the Hybrid Cloud