Microsoft may have remediated one vulnerability with its Windows Meltdown patches, but a security researcher said the fixes created a new, more dangerous flaw for some.

According to Ulf Frisk, a security researcher based in Sweden, the patches Microsoft released for Windows 7 x64 and Windows Server 2008 in January and February 2018 were successful in protecting against Meltdown but “opened up a vulnerability way worse” that could allow “any process to read the complete memory contents at gigabytes per second … [and] write to arbitrary memory as well.”

“The User/Supervisor permission bit was set to User in the PML4 self-referencing entry. This made the page tables available to user mode code in every process. The page tables should normally only be accessible by the kernel itself,” Frisk wrote in a blog post. “Once read/write access has been gained to the page tables it will be trivially easy to gain access to the complete physical memory, unless it is additionally protected by Extended Page Tables used for virtualization. All one has to do is to write their own Page Table Entries into the page tables to access arbitrary physical memory.”

Frisk developed a tool to test if a system is vulnerable, but noted that only systems running the patches from January or February will be at risk. “If your system isn’t patched since December 2017 or if it’s patched with the 2018-03 patches or later it will be secure,” he wrote.

A Microsoft spokesperson confirmed the company “is aware of this and looking into the matter further. This issue impacts Win7 SP1 (x64 only) and Server 2008R2 SP1 (x64 only). We are actively testing a solution, and will make it available as soon as it is properly validated.”

Mark Nunnikhoven, vice president of cloud security for Trend Micro, said it was important to note that the Windows Meltdown patches didn’t create a vulnerability to read the memory, but rather introduced “a misconfiguration that exposes memory unintentionally.”

This specific issue should never have shipped. It’s a process failure for sure.Mark Nunnikhovenvice president of cloud security for Trend Micro

“It’s not someone picking a lock and getting in; someone forgot to lock the door in the first place. It’s a quality control issue. Microsoft has a long history of good patches, but even the best processes aren’t perfect. There’s a lot of code in the operating system that relies on the CPU functioning in a specific way,” Nunnikhoven told SearchSecurity. “This was never going to be an easy fix. That said, this specific issue should never have shipped. It’s a process failure for sure.”

Experts react to Windows Meltdown patches

Tod Beardsley, research director at Rapid7, said Frisk’s research is solid but added that the risk might be lessened since “the exposure only lasted a couple months in almost all scenarios.”

“It would be unusual for Windows systems to get the January or February patches, but not yet have the March patches by now, since most enterprises that apply patches also tend to apply them automatically,” Beardsley told SearchSecurity. “However, if your enterprise fast-tracked Spectre and Meltdown patches back in January but hasn’t updated since, then now is a fine time to update — the exposure introduced in these patches are indeed worse than the original exposures. The same rationale for emergency patching in January certainly applies to this issue as well.

Jerome Segura, lead malware intelligence analyst at Malwarebytes, said the “daunting task” of creating the Windows Meltdown patches has led to a number of issues.

“The first patches that came out introduced not only a performance hit but also unwanted behavior such as system reboots, so much so that Intel even advised its customers to wait for a stable patch,” Segura told SearchSecurity. “This gives us an idea of the far reaching effects these vulnerabilities have, and for which we are still trying to grasp the extent of their ramifications.”