Vista UAC - time for DRM keyboard? | The Coffeehouse

Badgerguy
Badgerguy

I've been using Vista for a while now, and to get a feel for it - I've left UAC on.

This is a good thing, right? Well, no, because UAC is pretty annoying - a fact that becomes pretty clear given that most lists of 'Tips and Tricks' for Vista out on the net usually include the instructions for turning UAC off somewhere near the top.

The problem I see with UAC is it pops up usually to simply confirm a mouse click - I double click on a management console icon for example - and up pops a UAC prompt asking for confirmation.

So how is it that we have DRM technology that can protect content going out through the soundcard and even beyond, but we don't have any kind of DRM technology in keyboards and mice that might allow the OS to ensure that an initiated action is one being carreid out by the user with their input devices, and not by a malicious program or script?

If DRM was built into input devices, UAC could pop up allot less, not having to basically confirm mouse clicks on trusted software (such as microsoft's own built in consoles and control panels) - and allowing for three different levels of UAC: Off, On for untrusted software, and on for all actions.

Thoughts?

troposphere

Secure input devices is definitely in the works for "Trusted Computing."

Check out any reliable document on the subject, and it will mention it.

Bas
It finds lightbulbs.

First of all, I've been using Vista on a daily basis since the release, and I don't get any UAC popups during normal use. When installing an application, yes, but seeing how I'm going to click through a couple of wizard steps, I don't see how more click is so much worse. Any attempt to 'improve' UAC seems more hassle than it's worth, so far.

But anyway, it's an interesting idea, but it has one fatal weakness: for it to be inconspicuous, you'd have to get rid of the secure desktop. And as soon as the secure desktop is gone, the system is useless. After all, what would happen if some malicious tool managed to trick UAC into thinking it came from your secure input device?

W3bbo
The Master of Baiters

A "DRM Keyboard" would be a keyboard that detects keystrokes like "britney spears mp3s lol" or "isohunt.com" and sends an email off to the MAFIAA alerting them to your seemingly imminent copyright infringement.

No, what you refer to would be a "TPM Keyboard", a keyboard with a built-in TPM module that interacts with the TPM in the host-system to ensure all input can be trusted (or not)

Whilst an interesting idea, it wouldn't play well with the existing user-input architecture in Windows (or any other OS).

The rest of us just grin and bear it. I figure we'll eventually get malwares spoofing the UAC prompt, even those totally unconvincing PayPal phishes work against a lot of users, and Microsoft will have to rethink the whole thing.

Whilst Microsoft tightened security in Vista, I'd say it was done at great expense to usability. Apple pulls it off nicely enough.

Bas
It finds lightbulbs.

W3bbo wrote:
The rest of us just grin and bear it. I figure we'll eventually get malwares spoofing the UAC prompt

What would that achieve?

Sven Groot
My name has 9 letters. Coincidence? I think not...

Badgerguy wrote:
If DRM was built into input devices, UAC could pop up allot less

It would exclude things like speech recognition and other accessibility software though that simulate user actions for good reasons.

And it would make the nay-sayers go "M$ forces people to buy new keyboards".

littleguru
<3 Seattle

Why is this UAC-thread-creating-thing not stopping? This is the 60zillionth thread about it. Charles did even a video on why and how UAC, but nobody seems to watch that. Embarassed

W3bbo
The Master of Baiters

Bas wrote:

W3bbo wrote:The rest of us just grin and bear it. I figure we'll eventually get malwares spoofing the UAC prompt

What would that achieve?

Once a malware has your plaintext credentials it can hypothetically do anything, 'nuff said.

Sven Groot
My name has 9 letters. Coincidence? I think not...

W3bbo wrote:

Bas wrote:

W3bbo wrote: The rest of us just grin and bear it. I figure we'll eventually get malwares spoofing the UAC prompt

What would that achieve?

Once a malware has your plaintext credentials it can hypothetically do anything, 'nuff said.

1. For 90% of the population, who will run as a member of the Administrators group, UAC doesn't even ask for credentials (it's just a continue button).
2. Even with the username and password of an administrator code can't get elevated permissions without first getting a real UAC dialog. Runas alone will not work unless it's the built-in Administrator account (which is disabled by default). They can do all sorts of other nasty stuff with your credentials (impersonate you on the network, that sort of thing), but they can't elevate without actual user consent.
3. This is like the billionth time I've explained this on C9 alone.

EDIT: This article explains very nicely in its first few paragraphs what UAC does under the covers. If some malware uses runas with the credentials of an admin, the new process will still get a filtered token. To elevate you need a real UAC dialog, there's no other way (short of any bugs in UAC, of course).

Bas
It finds lightbulbs.

Sven Groot wrote:

W3bbo wrote:

Bas wrote:

W3bbo wrote: The rest of us just grin and bear it. I figure we'll eventually get malwares spoofing the UAC prompt

What would that achieve?

Once a malware has your plaintext credentials it can hypothetically do anything, 'nuff said.

1. For 90% of the population, who will run as a member of the Administrators group, UAC doesn't even ask for credentials (it's just a continue button).
2. Even with the username and password of an administrator code can't get elevated permissions without first getting a real UAC dialog. Runas alone will not work unless it's the built-in Administrator account (which is disabled by default). They can do all sorts of other nasty stuff with your credentials (impersonate you on the network, that sort of thing), but they can't elevate without actual user consent.

What he said. 'nuff said.

nlondon

I don't think the type of actions UAC is intended to protect you from is clicking a "Corrupt System Now" button... it is to protect you from clicking the innocent looking "Check for Updates Now" button in an untrusted app that is maliciously designed to corrupt your system. Just because you clicked it doesn't mean you should have clicked it.

Badgerguy
Badgerguy

nlondon wrote:
I don't think the type of actions UAC is intended to protect you from is clicking a "Corrupt System Now" button... it is to protect you from clicking the innocent looking "Check for Updates Now" button in an untrusted app that is maliciously designed to corrupt your system. Just because you clicked it doesn't mean you should have clicked it.

Preciesly why I quantified it by saying it should only apply to trusted software. Any application could try to do something at the click of a mouse - but only trusted software (ie software that can be verified to have been: a) installed with approval, and b) not tampered with since installation amongst other criteria), should be able to do things that are administrative tasks at the command of the user.

Not to mention that UAC could still be turned 'fully on' as it is now - it needn't be an either /or thing.

Badgerguy
Badgerguy

W3bbo wrote:

Whilst an interesting idea, it wouldn't play well with the existing user-input architecture in Windows (or any other OS)..

Oh definately - but it could be 'phased in' pretty easily. The reward for anyone with a TPM based PC with TPM based input devices would be the option of having fewer annoying UAC prompts.

As for other platforms - well, it depends on whether such a system would err on the side of security with TPM keyboards and mice ONLY working with a TPM enabled system - or, you could simply have a physical switch on the devices to turn TPM on or off.

Badgerguy
Badgerguy

Sven Groot wrote:

It would exclude things like speech recognition and other accessibility software though that simulate user actions for good reasons.

And it would make the nay-sayers go "M$ forces people to buy new keyboards".

Not necessarily - software that simulates input could in itself be protected with DRM, and interact with windows TPM systems.

As for the nay-sayers - well, the nay-sayers say nay to Microsoft in whatever they do, so it's not really a concern to me! Ultimately allot of UAC popups occur because the OS can't tel the difference between a 'simulated' input or action, or a user command that it is genuinely coming from the user by mouse click, or keystroke. A way needs to be found to fix it.

Jorgie
Jorgie

Badgerguy wrote:

Sven Groot wrote:
It would exclude things like speech recognition and other accessibility software though that simulate user actions for good reasons.

And it would make the nay-sayers go "M$ forces people to buy new keyboards".

Not necessarily - software that simulates input could in itself be protected with DRM, and interact with windows TPM systems.

What you are asking for is already there. The UAC prompt is in a trusted process that can only be accessed by other trusted processes. The only way a piece of software, malware or accessibility software, can touch it is if it already has fully trusted and elevated. In that situation it could do anything it wants without triggering UAC anyway.

Jorgie