SandWorm thrived thanks to botched MSFT patch says HP

Issues known and understood for at least two years before Shai-Hulud crawled out of the code

Sandworm vulnerability logo

Microsoft had a chance to crush the SandWorm bug before it crawled out of the dunes, but botched the job, says HP.

HP says that the Windows Object Packager, which SandWorm attacks, “had suffered a similar issue in 2012 with security bulletin MS12-005.

HP researcher Matt Oh goes on to write that he “found striking similarities“ between the patch for SandWorm, MS14-064, and the previous patch. Another patch, MS14-060, also addressed the underlying problem SandWorm exploits.

“Both MS12-005 and MS14-060 add code to mark files unsafe by using a zone identifier,” he writes. “This pops up a warning dialog box on the user’s screen before binaries are executed. This provides additional protection for the user - any embedded object dropped in the temporary folder from Office documents should be treated as potentially dangerous.”

Oh offers a detailed explanation of how SandWorm and its patches work, noting that the patch rollup MS14-064 also addressed the issue."

His assessment of the situation won't please Microsoft: “The problem is that the three patches touch on the same issues over and over again. MS12-005 introduced the MarkFileUnsafe function and applied it to two functions. Now MS14-060 applies the same patches to an additional three functions that perform very similar actions – file dropping. MS12-005 fixed an extension validation issue in the CPackage::DoVerb function by introducing a special registry key switch. MS14-064 fixed a very similar issue inside the exact same function by introducing a special registry key and confirmation message box.”

“Based on my findings, I think there was a good chance to fix the SandWorm vulnerability two years ago, before it was used by malware authors and became an issue,” he concludes. “We can’t reverse time, but we can, and should, learn from the past.” ®

Biting the hand that feeds IT © 1998–2018