Looks like there are clouds on the horizon. Another new 0day flaw has been discovered after the last one related to Windows Shell which Microsoft fixed this month. At least this is what we can read from some articles that are quickly spreading on the web.

From what we can read looks like this vulnerability allows an attacker to execute arbitrary code by forcing some applications loading malicious files. We currently aren't aware of any more detail about this flaw, and looks like Rapid7 company is going to release further details about it during next week. So we could just do some speculation about this 0day flaw.

The article explains that Apple iTunes software was vulnerable to such flaw and it has been fixed by Apple. It's enough to read Apple security bulletin to realize that this kind of 0day attack maybe is not all that new.

Apple security bulletin writes:

A path searching issue exists in iTunes. iTunes will search for a specific DLL in the current working directory. If someone places a maliciously crafted file with a specific name in a directory, opening another file in that directory in iTunes may lead to arbitrary code execution. This issue is addressed by removing the code that uses the DLL

This reminds me so much an old injection trick used by malware since years. The key word looks like is: Dynamic-Link Library Search Order.

What we are talking about? When an application tries to load a specific module into the address space of the calling process, it usually uses the Windows APIs LoadLibrary / LoadLibraryEx - at least if you want to follow the documented way.

One of the parameters accepted by these APIs is the path to the library that is wanted to be loaded. If the developer just specifies module name without a path, the operating system starts searching this module by looking in a number of known paths.

This list of known paths is called Dynamic-Link Library Search Order, and it is clearly documented on Microsoft's MSDN. The list depends on the operating system settings, anyway the most common is the one below:

- The directory from which the application loaded.

- The system directory. Use the GetSystemDirectory function to get the path of this directory.

- The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.

- The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.

- The current directory.

- The directories that are listed in the PATH environment variable.

So, if the application is loading a module by specifying only its name, the operating system at first check if the wanted module is a known module (they are listed inside KnownDLLs registry key). If not, it starts looking at each one of the paths listed above, starting from the first till the last.

For instance, if the module is found in the directory from which the application loaded, Windows stops the search and loads this module.

Now, it should become clear how this Windows feature could be abused by malicious attackers.

While it could be questionable the implementation of such search order, I don't think it's a Windows operating system problem itself. The logic behind runtime module loading is well documented by Microsoft and explained on MSDN. Moreover, both search order and LoadLibrary/LoadLibraryEx functions are well documented. This become then a problem of software developers, whether they decided to follow Microsoft's development guidelines or not. Actually this Windows behavior has been exploited since years by malwares and it has been discussed online many times.

We actually don't know if this is the flaw discussed in the article, we only know that it would be in case an old-new 0day flaw.

But, again,it's only speculation. We have just to wait for someone releasing more details about it.