The recent turmoil on UAC seemed to be settled by Microsoft last week (my take on the issue). But now it’s time to question UAC again. This article explains that Microsoft is going in the wrong direction with UAC. From an annoying dialog that gives some security, it has degraded to just an annoying dialog.

Microsoft is now betting on what they call “trusted processes”: processes that are considered trusted so they don’t trigger a UAC dialog. A lot of those processes (like rundll32) are specifically designed to run external (untrusted) code:

In short, trusting executables is a poor policy, because so many executables can be encouraged to run arbitrary code. There is some irony in Microsoft’s behavior to use a trusted executable model; the company knows damn well that trusted executables aren’t safe, and uses this very argument to justify the UAC behavior in Vista. A system using trusted executables will only be secure if all of those executables are unable to run arbitrary code (either deliberately or through exploitation).

In other words (from the article mentioned above):

So, in spite of the most recent blog post, this remains a poorly-designed feature. UAC is now only as strong as the weakest auto-elevating program.

I wonder what happened to Microsoft’s security drive given these developments with Windows 7 security efforts.