Due To "Windows Kernel Bug" Security Software Doesn't Detect Malware

Due To "Windows Kernel Bug" Security Software Doesn't Detect Malware

There is a decade old bug in Windows kernel that can be easily exploited to prevent security apps from identifying malicious programs loaded at runtime.

The bug is so old that it dates back to Windows 2000 and is found in all the subsequent Windows OS versions including the most recent release while the actual issue underlies with the PsSetLoadImageNotifyRoutine. This is a feature in Microsoft OS that notifies developers about the drives that are newly registered. Therefore, the bug is quite serious as it renders security tools useless as it blocks the program’s ability to detect malware threats.

Researchers identified that “after registering a notification routine for loaded PE images with the kernel the callback may receive invalid image names.”

This means, when the registered notification routine was invoked, the kernel supplied a series of parameters, which then initiated proper identification of the PE image that was being loaded. The parameters are part of the prototype definition of the callback function.

“This flaw exists in the most recent Windows 10 release and past versions of the OS, dating back to Windows 2000”

“This bug has security implications on security vendors that rely on Microsoft documentation when using the API in order to monitor loaded files. Since there is no documentation of the bug and no formal workaround, this can potentially cause security vendors to miss malware. We are not aware of any intention to create a fix to this,” Yavo told SecurityWeek.

Yavo however, admitted that the routine doesn’t function as it is being specified.

“Some references indicate the bug was somewhat known, but… its root cause and full implications weren’t described in detail up until now,” read the blog post on enSilo.

To resolve the issue, Microsoft suggests using a file-system mini-filter callback to monitor PE image files loaded to the virtual memory as executable code. However, researchers claim that this method is useless because it cannot be used to determine if the section object is created for the loading of PE image file or not since enSilo researchers have noted that the parameter that identified the loaded PE image file effectively is the FullImageName parameter.

They also claimed that kernel utilizes an entirely different format for FullImageName. The paths that are provided for dynamically loaded user-mode PE files don’t have the volume name, and in some instances, the path is malformed to such an extent that it even points to a completely different file and sometimes it leads to a non-existent file altogether.





Researchers conclude after thorough analysis that the Cache Manager and the way file-system driver maintains file name are responsible for the errors and a coding error eventually causes the invalid name issue to take place.