UAC Prompt Circumvention...it's really not a big deal....

I was part of the team that designed UAC. I’ll give you a little insight into the history of UAC and address some of the comments made on this blog post. Here we go…

As with any major initiative, especially one involving a multi-year effort involving 10s of engineers and affecting every application on the face of the earth, you don’t always end up with the exact technology you envisioned when you started. Hell, in the case of UAC we even changed the name of the feature several times – I bet no one remembers that it was called Flexible Account Control Technologies at one point. :)

If my memory serves me, when we started the UAC project, we firmly believed it would be a security feature. We wanted to protect users on the Windows system from malware. We also had the goal of incentivizing the use of Standard User accounts, which is something MSFT has been trying to do for several releases of Windows.

From my perspective, the design was brilliant and I take no credit for the creation of the split token. That concept was extremely powerful though because it modeled the default token to be that of a Standard User. In Vista, there was no compromise when it came to prompting and I remember answering the question “is there a white list for applications?” in every UAC talk I ever gave. Have no false pretense, that prompt isn’t security theatre – it is a giant stop sign that says: “This ISV wrote software that unnecessarily requires Administrator privileges!” This is exactly why you see the prompts today on Windows 7 targetted at 3rd parties.

As for the security messaging around UAC. The point where our messaging switched from security to reliability was when the product team engaged the support of our Secure Windows Initiative (SWI) team to PenTest UAC. They clearly demonstrated because of the shared state, HKCU, user profile, etc., between the “little Abby” and “big Abby” tokens (as we referred to them) that UAC elevations could never be a security feature – this was also right around when MarkRuss came to MSFT. He was also instrumental in demonstrating the flaws in our messaging!

I’ll admit that the product team was taken aback by this change in messaging and it took some of us longer than others to adjust to the new messaging. The good news is that I believe everyone at MSFT recognizes that UAC elevations (particularly for PA accounts, but also for Standard User accounts) is not a security boundary. If you want the highest level of security…never elevate a standard user account in an interactive session – this is achievable in an enterprise.

I have personally corrected several of the old documents with that messaging and I’m happy to fix any others if you send me an email with the link: chris@chriscorio.com. I didn’t see any in the top 10 in the list that accompanies this blog post (most of which are not written by offical MSFT employees) aside from the Windows help, which demonstrates the vintage of the messaging: http://windowshelp.microsoft.com/Windows/en-US/help/0eeb9ddd-ddaa-4cc5-a092-9908305665471033.mspx

Now, where are we today? I’ve seen an incredible interest from IT professionals in running their systems as Standard Users. This is a giant success and UAC was integral in achieving it. Those machines will run smoother and more reliably. As pointed out on the thread, the default account created in the Windows Out-of-Box Experience is still an Administrator. This is disappointing for me but MSFT has prioritized the UX for Windows right now and I think it is a necessary focus. Hopefully we will see this change in the future.

If anyone would like to have a public debate about UAC at any time – please don’t hesitate to let me know. Just send over a list of questions and I’m happy to answer them. I will be blunt in saying that I regard the dramatic posts around this elevation vulnerability as simply being a laughable distraction.

One thing that should never be forgotten: Malware writers are very sophisticated. They surely have far more interesting exploits than this fairly rudimentary workaround. And, for all you security researchers out there, this debate makes me chuckle…why does malware need administrator privileges anyway?

For now, I’m focusing on moving the broader industry to Standard User accounts, one desktop and one more fixed application at a time.

Chris