There are some indications and rumours running around about a new explosive 0 day for windows. Let's clear that up before you start looking in the wrong places and to warn you that for securitypeople there is an enormous task brewing behind it (this is why everybody is keeping for the moment quite silent about the facts - a good indication that something is very wrong - remember the DNS and the SSL bugs for starters).
This post is based upon the available information from different sources that are trying to put the pieces together.
This is the information as we know them today
This is NOT a windows bug. The windows kernel and OS has NOTHING to do with it. Keep that in mind while reading further.
It began with a mistake in the Apple Itunes software for windows (for those who think that installing applesoftware will make their PC safer :) ). That bug is fixed with the latest update (go to http://update.microsoft.com)
To function each program has to load different DLL's that should be located in a specific folder and sometimes are placed all over the system (more difficult to manage). If you don't like this kind of installation look for portable or installation-free software (and bypass the limitations placed on your workcomputer by installing them between your documents :) )
Now read the following very carefully because if this may be true, I think we have an enormous problem
"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.
The attack is very simple and can be industrialized by a botnet. You only have to place a DLL with the same name as the program will be searching for in one of the places windows will be looking first. This means that if the programmer has installed the DLL in the third place windows will automatically search for it and didn't specify the full location of the DLL that the program has to launch, than all a malware coder has to do is to place a bit of code with the same name in the first or second place Windows will search for it and the program will launch it.
If he is smart he will start an update process and can start downloading other stuff during the so-called installation process. You can imagine that many users will simply click us to upgrade or extended because the alert seems to come from the program itself. Or he could install other functions later.
There will be at least 40 popular and important windows applications that could be vulnerable.
But if you will take every software into account it can be much more.
now if you have a software restriction policy you can be saved because you only have so many programs to watch out for updates. It means also that you will need a full update policy for all the programs you are using because it means that now that some popular programs are trying to get a securitypolicy together other usertools can also become the target if they made several mistake in the programming and architecture.
IT-Security is an ever moving field
THis one could become important for software. Curious if this would also work in Linux or Apple.
THis shows the importance of SDL secure Development Lifecycle and the test phases that have to be set up during it.
Did your progammers follow any course on that ? Are your outsourced development firms certified ?
Oh that would cost more.... How much would it cost to adapt you software if this attack becomes generic (this means that it becomes an attack independent of the software or the code like a bruteforce attack for example).
How much of your software has been tested for bugs ? And how many of those bugs have been corrected ?
You understand now why this can be such an important story equal to the DNS and the SSL bugs.... Wait and see.