This is exactly the case with this individual. He refers to a very old attack vector when creating a DLL with the same name as one that was loaded by the application resulted in loading the “malicious” DLL. As of WinXP SP2 (which everyone should have installed by now, otherwise your computer won’t last for 10 minutes on the Internet), the search order for DLLs is the following (taken from the official MS page):

1. The directory from which the application loaded.
2. The system directory.
3. The 16-bit system directory.
4. The Windows directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.

Now lets analyze this list from the point of view of IE. The current security settings on my IE folder (in program files) is the following: Administratos – Full Control, Power Users – Modify and Users – Read and Execute. In other words you can only create files there if you have at least power user privileges, but if malicious code runs at that level you are pretty much screwed anyway as you can do much more damage than that.

Now if you run as a normal user (which you should be!), your only hope is to write to a directory in the path (or alternatively change your path so that it includes a given directory). In this case the DLL would be loaded IF it couldn’t be found in any of the other places. This scenario is only possible if some application uninstalled itself and failed to remove the registry entry for the DLL.

To sum up:

• This vulnerability has been fixed a couple of years ago (in WinXP SP2)
• If you run your browser with high privileges, you don’t need this method to alter the system. It can be used to hide files, but then again if you have that high privileges you can directly install rootkits.
• If you run with low privileges (as you should), the only attack would only be possible if you uninstalled a program which registered a BHO without referring with the full pathname to it and the uninstaller program deleted the dll, but failed to delete the registry entry. With other words: very, very unlikely.

My advice would be: run with low privileges (as user) and don’t read articles from people who don’t know what they’re talking about.

Listen to the whole podcast

First let me give a little background as I see it so that if they choose to answer my question (no offense, but if it is as I suspect, they are limited in their freedom of speech regarding this areas by NDAs and such) they can do so in the correct context. One of the biggest security advantages of IE7 is the so called containment wall, which if I understand correctly uses the x86/x64 architecture and the Windows NT security system to separate in different processes the different tasks the browser has, so that a lower privilege task can’t corrupt the memory of a higher privileged task. I think that this is a very robust solution which should reduce the attack surface considerably and I also can appreciate the work that most have gone into slicing up the application in parts. Now my question would be: is there any real technical reason for which this won’t be available under non-Vista versions of Windows? If possible name at least one API which this feature needs that is not available under non-Vista Windowses.. Because all of the mentioned techniques are available on all version of Windows from Win2K onwards (as for example the DropMyRigths tool written by Michael Howard demonstrates). I’m very curious if and what they’ll respond, but I have several possible scenarios in my mind: (a) I’ve misunderstood the feature and it’s really more or different from what I’ve described (moderately possible) (b) This is a marketing move which incorrectly puts revenue generating in front of security (this is my personal opinion, but I don’t think they will admit to it) or (c) my question won’t be asked at all.

Update: the guys over at the boagworld forum pointed out two more editors: DevEdit and Dojokit.