posted by Thom Holwerda on Mon 3rd Aug 2009 22:56 UTC
IconThe media might be heralding Windows 7 as the Windows release which will erase all the bad Vista memories, but there's still this nagging security flaw in Windows 7's User Account Control which Microsoft refuses to fix, stating that it is not a security flaw at all. Well, Microsoft, if this is not a security flaw - then why does your security software block the tool that demonstrates the flaw?

I'm not going to detail the security flaw yet again, but the general gist is that it's quite easy to bypass the default settings in Windows 7's UAC by piggybacking on processes in the operating system that are on a magic auto-elevate list. This list allows Microsoft to not fix their own code to work with UAC, while still demanding from other developers that they do fix their code.

Microsoft tried to weasel its way out of this situation by consistently claiming that the security flaw was not actually a security flaw, but "by design". Microsoft said that several other security barriers were in place to mitigate the flaw.

This does raise the question: why does Microsoft's Security Essentials beta specifically block the proof-of-concept code from running? This code is made solely to demonstrate the flaw, and Microsoft went through all the trouble of properly detecting and naming it for the Security Essentials beta to detect it. The code is open source, and a simple recompile using the Visual C++ 10.0 toolkit using VS 2010 Beta allowed the code to run undetected once again.

If the security hole is actually not a security hole, then why does Microsoft specifically block the tool that is designed to exploit it? Not only is it a cheap way to make it seem as if the hole is plugged, it's also an admission by Microsoft that we were right all along: yes, this is a security hole. Whether Microsoft wants to actually admit it or not.

e p (8)    42 Comment(s)

Technology White Papers

See More