Comment Re:Application developers fault (Score 1) 178
Microsoft created a liberal dynamic library search path that allows (or even encourages) applications to not fully specify DLL locations. Now, after the fact, they publish this security statement saying not to use the dynamic library searching they documented previously.
So basically, your suggestion is to design an OS that ensures that it is secure by taking away API calls that could be misused in a way that compromises security? By your own admission, it is a documented specification, and it is behaving exactly as it is intended to do so. It isn't a "bug" in the API, it's misuse by various developers. However, Microsoft is at fault for how developers (its own or 3rd-party) misuse an API call that is fully documented and behaving exactly as intended? This makes absolute, perfect sense.
It is of course Microsoft's fault. They didn't consider security at all when loading DLLs, and now they are blaming applications that implemented the documented specification.
Yes, they are blaming applications that have incorrectly used the documented specification. And, they have provided the capability to control remote loading of DLLs through a patch that can be targetted at individual applications or the entire OS. What more can reasonably be done?
The bottom line is that Windows was never designed to be secure, it was designed to have the most functionality, and trying to patch every hole now is almost impossible. Generally, when code reaches this level of complexity and brittleness, it is often the best course to start all over.
And this is factually wrong. Windows NT (as opposed to Windows) was designed from Day 1 to be secure. You can argue whether they succeeded in developing a secure OS, and that might be a far more interesting debate, but to argue that it was never designed to be secure is incorrect. This is a fact of historical record. I'd argue that earlier versions of Windows NT were significantly flawed from a security perspective while modern versions (Vista and newer) are significantly improved, but that's another debate.
Essentially, your entire argument is that it is Microsoft's fault for providing a documented API that can be misused. I'll grant the defaults could have been chosen better, but competent programmers need to be aware of these issues. I'm mildly surprised it's getting the coverage it is, as this isn't some brand new attack; this issue has been known about for some time and not gotten a lot of coverage because it simply isn't that big a deal and is not a flaw in the underlying OS. For example, this blog post from early 2008 covers the issue (and was linked in some more recent blog posts): DLL Preloading Attacks