Installing Web plug-ins as a Vista non-administrative user
by ZDNet Author | March 7, 2007 6:44am PST | Image 1 of 27
Previous | Next
Selecting a video to view from iFilm.com
Just prior to the Super Bowl, we went to iFilm.com to get an early peek at some of the commercials that were going to air during the football game. I picked the commercial for a Ford F-Series pickup truck.
For David Berlind's write-up on ActiveX control security in Vista and Internet Explorer 7, see his post in ZDNet's TestBed blog.
For David Berlind's write-up on ActiveX control security in Vista and Internet Explorer 7, see his post in ZDNet's TestBed blog.
Just In
Screenshot 9 (Security Settings - Internet Zone) has an error in its description regarding "Download signed ActiveX controls." Your description says "It was disabled by default." This is false. The IE default for this setting in the Internet Zone is "Prompt".
For the Java installation, it looks like you are running an EXE file. It's showing the description and publisher of the EXE file.
For ActiveX controls, installed via an object tag's codebase attribute (e.g. <object classid="..." codebase="http://www.example.com/foo.cab">), you get the generic Add-on Installer prompt. The Add-on Installer is simply the file "ieinstal.exe" located in C:\Program Files\Internet Explorer.
P.S. "It doesn't say anything about Adobe's Acrobat." Of course it doesn't, you're installing Flash! :-p
For ActiveX controls, installed via an object tag's codebase attribute (e.g. <object classid="..." codebase="http://www.example.com/foo.cab">), you get the generic Add-on Installer prompt. The Add-on Installer is simply the file "ieinstal.exe" located in C:\Program Files\Internet Explorer.
P.S. "It doesn't say anything about Adobe's Acrobat." Of course it doesn't, you're installing Flash! :-p
and got nothing of the sort. I was even able to run it as an LPU. This appears to be an issue of running vs. installing which raises the question of whether exectuables should have to register at the front door before they're allowed to run. I believe some personal firewalls double check before they allow certain EXEs to run the first time. Maybe Sygate?
Thanks for the spot on the Acrobat thing. It's corrected.
db
Thanks for the spot on the Acrobat thing. It's corrected.
db
... on whether the application is marked as requiring elevation.
If the creator of the EXE knows they always want the app to run as administrator, they can flag it as such by using new field in the EXE's embedded manifest. Windows will then always display the UAC prompt for that EXE. (This flagging is new for Vista.)
If the app isn't flagged (for example, it's designed pre-Vista), Windows uses heursistics to determine if it is probably a setup file. It looks for words such as "setup" or "install" in the EXE name and the EXE's description string. If so, Windows treats it as an installer and will give the UAC prompt.
The other EXE you tried must not have been flagged as requiring admin priviliges, and must not have had anything that set off the heuristics.
If the creator of the EXE knows they always want the app to run as administrator, they can flag it as such by using new field in the EXE's embedded manifest. Windows will then always display the UAC prompt for that EXE. (This flagging is new for Vista.)
If the app isn't flagged (for example, it's designed pre-Vista), Windows uses heursistics to determine if it is probably a setup file. It looks for words such as "setup" or "install" in the EXE name and the EXE's description string. If so, Windows treats it as an installer and will give the UAC prompt.
The other EXE you tried must not have been flagged as requiring admin priviliges, and must not have had anything that set off the heuristics.
You said "If the creator of the EXE knows they always want the app to run as administrator, they can flag it as such by using new field in the EXE's embedded manifest."
Well, this means that as long as some hacker creates an EXE he wants to fly below the radar, then no problem. The EXE I'm talking about runs perfectly fine.. no interruptions...even if the user is a lesser privileged user.
I think Vista is flagging the wrong thing. It's looking for installers. It should be looking for new, unregistered EXEs, DLLs, etc. that have never been run in the OS before. Especially under an LPU. Take this ability in combination with no outbound blocking on the firewall, and now you understand why I think an outbound blocking firewall (one that's not set to let everything through by default) is needed.
db
Well, this means that as long as some hacker creates an EXE he wants to fly below the radar, then no problem. The EXE I'm talking about runs perfectly fine.. no interruptions...even if the user is a lesser privileged user.
I think Vista is flagging the wrong thing. It's looking for installers. It should be looking for new, unregistered EXEs, DLLs, etc. that have never been run in the OS before. Especially under an LPU. Take this ability in combination with no outbound blocking on the firewall, and now you understand why I think an outbound blocking firewall (one that's not set to let everything through by default) is needed.
db
I agree that it doesn't make sense that you have to give UAC consent before viewing the Authenticode dialog. But if you think about it, it does make sense. Let's pretend that the Authenticode dialog came first -- here's what might happen.
You are running IE in Protected Mode. As such, everything happening in the IE process is sandboxed, and could be in the process of being compromised -- let's say that an attacker is taking advantage of a zero-day exploit in the HTML parser, and is able to run any code he desires.
He could try to trigger the installation of a malicious ActiveX control. In our alternate scenario, this would show the Authenticode dialog; however, since the attacker has already compromised IE, he could modify the Authenticode dialog so that it displays "Adobe Flash Player" instead (spoofing). The user thinks she's about to install Flash, when there's really a malicious control in waiting.
So, let's say the user clicks Install on the spoofed Authenticode dialog. This would then lead to the UAC prompt -- the IE Add-on Installer, trying to install tha malicious control. The UAC prompt doesn't say what control it is, but the user would think, "I just saw what it's for, it's for Flash," so she enters her password in the UAC dialog. In our scenario, the UAC prompt is the last step, so immediately after approving the UAC dialog, the malicious control is installed.
Another scenario: Instead of triggering control installation in the normal way and spoofing the Authenticode dialog, the attacker skips that and simply executes the same code that the protected mode IE does in order to trigger the Add-on Installer UAC dialog. In this case, the first thing the user sees is the UAC dialog--and that's the last thing, too. Malware installed. (This is another reason that I am against the "whitelist" of controls that bypass the goldbar. UAC prompts should never be out of nowhere.)
The thing that a user would need to know, is that if they see the Add-on Installer UAC prompt, they will always subsequently see the Authenticode dialog from which they can make the choice of whether to install. The attacker who has compromised the protected mode IE process cannot supress or spoof the Authenticode dialog since it is running at a different integrity level; it will always be displayed and its contents are genuine.
So, that's the reason why it is the way it is. It's definitely not a perfect user experience. Ideally, the Add-on Installer UAC prompt would display the authenticode information directly in it.
You are running IE in Protected Mode. As such, everything happening in the IE process is sandboxed, and could be in the process of being compromised -- let's say that an attacker is taking advantage of a zero-day exploit in the HTML parser, and is able to run any code he desires.
He could try to trigger the installation of a malicious ActiveX control. In our alternate scenario, this would show the Authenticode dialog; however, since the attacker has already compromised IE, he could modify the Authenticode dialog so that it displays "Adobe Flash Player" instead (spoofing). The user thinks she's about to install Flash, when there's really a malicious control in waiting.
So, let's say the user clicks Install on the spoofed Authenticode dialog. This would then lead to the UAC prompt -- the IE Add-on Installer, trying to install tha malicious control. The UAC prompt doesn't say what control it is, but the user would think, "I just saw what it's for, it's for Flash," so she enters her password in the UAC dialog. In our scenario, the UAC prompt is the last step, so immediately after approving the UAC dialog, the malicious control is installed.
Another scenario: Instead of triggering control installation in the normal way and spoofing the Authenticode dialog, the attacker skips that and simply executes the same code that the protected mode IE does in order to trigger the Add-on Installer UAC dialog. In this case, the first thing the user sees is the UAC dialog--and that's the last thing, too. Malware installed. (This is another reason that I am against the "whitelist" of controls that bypass the goldbar. UAC prompts should never be out of nowhere.)
The thing that a user would need to know, is that if they see the Add-on Installer UAC prompt, they will always subsequently see the Authenticode dialog from which they can make the choice of whether to install. The attacker who has compromised the protected mode IE process cannot supress or spoof the Authenticode dialog since it is running at a different integrity level; it will always be displayed and its contents are genuine.
So, that's the reason why it is the way it is. It's definitely not a perfect user experience. Ideally, the Add-on Installer UAC prompt would display the authenticode information directly in it.
First, my feeling is that ANY time the UAC dialog pops up, you should take that seriously as some code attempting to execute and not allow it unless you had the expectation that something you wanted to run is trying to run.
I just ran a test with a Windows application that requires nothing but one EXE and one DLL to run. In other words, their simple presence in a directory (even a USB key) is all that's required for the Winapp to run and it works just fine if you're logged in as an LPU. I can walk up to your PC, drop in a USB key, wait for Vista to give me a folder icon to click on, and double click the app.
So, ANYTHING could pop up what appears to be an authenticode dialog (it could be nothing of the sort). This is why I think it makes more sense to have the UAC after. Because if that *anything* can spoof a UAC dialog, then it can also do anything else once it has been given the keys to the Vista kingdom.
db
I just ran a test with a Windows application that requires nothing but one EXE and one DLL to run. In other words, their simple presence in a directory (even a USB key) is all that's required for the Winapp to run and it works just fine if you're logged in as an LPU. I can walk up to your PC, drop in a USB key, wait for Vista to give me a folder icon to click on, and double click the app.
So, ANYTHING could pop up what appears to be an authenticode dialog (it could be nothing of the sort). This is why I think it makes more sense to have the UAC after. Because if that *anything* can spoof a UAC dialog, then it can also do anything else once it has been given the keys to the Vista kingdom.
db
For IE, when running in the protected mode process, everything is untrusted. If that process is compromised, you can't trust anything you see there. If the authenticode dialog was displayed by protected IE, it couldn't be trusted.
The authenticode dialog that appears after the UAC dialog is running outside of the protected mode process, in a higher integrity level, so it cannot be affected by the protected IE process (which an attacker may have control over). You can trust whatever that authenticode dialog says when it is being displayed by the IE Add-on Installer.
I do agree that a UAC dialog appearing out of nowhere is bad. At least by "approving" an install via the goldbar, you are expecting a UAC to follow that. (That's why I hate the whitelisted controls like Flash -- those UAC prompts aren't the result of a direct user action.)
To trust the sequence of events, the user needs to know that anytime the "IE Add-on Installer" wants to elevate, they will be given a chance to approve/deny the install after elevating. I agree that this isn't the best experience, because you really should have everything you need to know displayed in the UAC dialog itself. Maybe they'll smooth this out for Vienna.
But does it at least make sense why the Authenticode dialog doesn't come first?
The authenticode dialog that appears after the UAC dialog is running outside of the protected mode process, in a higher integrity level, so it cannot be affected by the protected IE process (which an attacker may have control over). You can trust whatever that authenticode dialog says when it is being displayed by the IE Add-on Installer.
I do agree that a UAC dialog appearing out of nowhere is bad. At least by "approving" an install via the goldbar, you are expecting a UAC to follow that. (That's why I hate the whitelisted controls like Flash -- those UAC prompts aren't the result of a direct user action.)
To trust the sequence of events, the user needs to know that anytime the "IE Add-on Installer" wants to elevate, they will be given a chance to approve/deny the install after elevating. I agree that this isn't the best experience, because you really should have everything you need to know displayed in the UAC dialog itself. Maybe they'll smooth this out for Vienna.
But does it at least make sense why the Authenticode dialog doesn't come first?
"One other interesting point.. check out the "action" that this User Account Control dialog is flagging. It says "Internet Explorer Add-on Installer." It doesn't say anything about Adobe's Acrobat. Why is this interesting?"
Because you were trying to install Adobe Flash Player???
Sorry, couldn't resist
Because you were trying to install Adobe Flash Player???
Sorry, couldn't resist
About time. You know how many people install viruses because they willy-nilly download everything they see on the Internet?
And I'd personally set it to prompt to download the controls, not download them automatically. If downloading is done automatically, you are asking for a drive-by download which could contain a virus.
And I'd personally set it to prompt to download the controls, not download them automatically. If downloading is done automatically, you are asking for a drive-by download which could contain a virus.
In addition I found that I.E. 7 phishing Filter does not always detect because my other phishing Filter noticed something I saw as a problem, therefore you have a good idea there. Someone managed to get passed the I.E. 7 Phishing Filter, they could work on getting passed other things, all they need to do is find what works. If you can see what problem there is, you can stop it before it happens, not always possible, yet worth the effort if you can.
The only problem I see is that you had install yahoo toolbar checked in the install flash player screen.
lol...if you looking for some bad computer problems and slowdowns in the future this would be the reason...Windows should nix that toolbar crap and never allow half ass programs like that to ever insall...it is just free moneyware for adobe anyways.
lol...if you looking for some bad computer problems and slowdowns in the future this would be the reason...Windows should nix that toolbar crap and never allow half ass programs like that to ever insall...it is just free moneyware for adobe anyways.
Join the conversation!
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
Vendor Showcase
Facebook Activity
