|
|
User Controls
|
New User
|
Login
|
Edit/View My Profile
|
|
|
|
ActiveMac
|
Articles
|
Forums
|
Links
|
News
|
News Search
|
Reviews
|
|
|
|
News Centers
|
Windows/Microsoft
|
DVD
|
ActiveHardware
|
Xbox
|
MaINTosh
|
News Search
|
|
|
|
ANet Chats
|
The Lobby
|
Special Events Room
|
Developer's Lounge
|
XBox Chat
|
|
|
|
FAQ's
|
Windows 98/98 SE
|
Windows 2000
|
Windows Me
|
Windows "Whistler" XP
|
Windows CE
|
Internet Explorer 6
|
Internet Explorer 5
|
Xbox
|
DirectX
|
DVD's
|
|
|
|
TopTechTips
|
Registry Tips
|
Windows 95/98
|
Windows 2000
|
Internet Explorer 4
|
Internet Explorer 5
|
Windows NT Tips
|
Program Tips
|
Easter Eggs
|
Hardware
|
DVD
|
|
|
|
Latest Reviews
|
Applications
|
Microsoft Windows XP Professional
|
Norton SystemWorks 2002
|
|
Hardware
|
Intel Personal Audio Player
3000
|
Microsoft Wireless IntelliMouse
Explorer
|
|
|
|
Site News/Info
|
About This Site
|
Affiliates
|
ANet Forums
|
Contact Us
|
Default Home Page
|
Link To Us
|
Links
|
Member Pages
|
Site Search
|
Awards
|
|
|
|
Credits
©1997/2004, Active Network. All
Rights Reserved.
Layout & Design by
Designer Dream. Content
written by the Active Network team. Please click
here for full terms of
use and restrictions or read our
Privacy Statement.
|
|
|
|
|
|
|
|
Time:
00:00 EST/05:00 GMT | News Source:
ZDNet |
Posted By: Kenneth van Surksum |
Despite all the anti-malware roadblocks built into Windows Vista, a senior Microsoft official is lowering the security expectations, warning that viruses, password-stealing Trojans and rootkits will continue to thrive as malware authors adapt to the new operating system.
Mark Russinovich, technical fellow in Microsoft's Platform and Services Division, used the spotlight of the CanSecWest security conference in Vancouver to discuss the implementation of UAC (User Account Control) in Windows Vista and made it clear that the feature is not meant to be a security barrier.
"It's a best effort to raise the bar and stop malware from making changes to the operating system but it's not a security boundary," Russinovich said of UAC, the oft-criticized mechanism that requires that all users run without full admin rights.
|
|
#1 By
8556 (12.207.97.148)
at
4/24/2007 8:20:09 AM
|
The UAC is very poorly implemented. Any 3 year old can figure out that clicking on Allow will let their cute freebies install off any bogus web link. It would have made far more sense for Microsoft to program Vista to ask for a user password, instead of Cancel or Allow. This would prevent visitors, drunk or sober, from installing malware. UAC for this reason is only a partial path to improved security.
|
#2 By
23275 (24.179.4.158)
at
4/24/2007 8:40:15 AM
|
This is so misleading. Windows Vista's UAC does require a password from an administrative user for all accounts that are not designated as administrators.
All administrative user accounts are themselves restricted user accounts - aside from such users not having to enter an actual password.
The built-in Root-Level admin account in Vista is disabled by default.
During setup, or the out of box experience - be it one that an OEM provides, or the user creates upon set up, it makes sense for the account created to be a non-Root level admin account - so the new user has the authority to create non-admin restricted user accounts as advised.
A lot of confusion persists around UAC and the facts are not being presented well, or they are selectively ignored by the press reporting about it. This is unfortunate and it is not serving users well at all - especially new users, or those less familiar with using operating systems that observe least privileged user rights assignments.
|
#5 By
8556 (12.207.97.148)
at
4/24/2007 1:15:45 PM
|
lketchum: When one is presented with Cancel or Allow to run a utility, or install a program, than anyone with access to any Vista machine, after booting, can create problems intentionally or no. Linux and OS X ask for passwords to install updates etc,. Vista does not ask for paswords to install a program, by default.
This post was edited by bobsireno on Tuesday, April 24, 2007 at 13:18.
|
#6 By
32132 (142.32.208.234)
at
4/24/2007 1:39:54 PM
|
#5 In what way is clicking a button or typing a password significantly different for the average user?
If the user (with Admin rights) mindlessly clicks on the OK button, whats to stop them from mindlessly typing in a password?
The purpose of UAC is to make some people think about what they are doing and to prvent silent installs.
Making them type in a password would just encourage many to turn off UAC.
|
#7 By
7754 (216.160.8.41)
at
4/24/2007 1:58:42 PM
|
I think what Russinovich is getting at is partly a semantic difference, and partly an explanation of the state of the malware "industry." The way he refers to "security barrier" is more in a definitive sense and unlikely to be taken or understood in the same way by an end-user, which leads to some confusion. The explanation is simply that malware writers will simply be required (as I suspected would happen) to move on to privilege escalation exploits and exploits that cause damage within the context of a standard user's permission level. His description of malware writers being like "ISVs that will code for a standard user environment" is very apt.
The implied notion in the article is that it is impossible for a standard user account to do anything malicious whatsoever, which is simply not true. UAC itself wouldn't prevent a user from running something that would delete all the files in the Documents folder, for instance. The amount of damage that can be done to the operating system is exceptionally limited (bar an escalation), but that doesn't mean that other types of malicious activities can't be performed.
|
#8 By
7754 (216.160.8.41)
at
4/24/2007 2:31:12 PM
|
#5: I also think it should require a password, but technically, we're talking about different things here. When running as non-root/admin in Vista, it *will* require a password by default.
In defense of UAC, it is much more granular than sudo in Linux/OS X. It does not, for instance, have the "5 minute" sudo vulnerability.
|
#9 By
8556 (12.207.97.148)
at
4/24/2007 3:49:47 PM
|
NotParker: the idea is that you keep your password to yourself and don't have a post-it note next to the monitor so visitors, and/or their kids, that discovered your computer aren't given full rights to install anything. A private password does that, if its kept private. Cancel or Allow doesn't block anyone sitting at a machine from running anything they want to on Vista as supplied. Most users will allow visiting relatives to use their PC. Without password protection, for installs, these machines will ALLOW much of the same crap as XP to be installed.
|
#10 By
23275 (172.16.10.31)
at
4/24/2007 4:18:28 PM
|
All: addressing the entire "mindless response" bit....
First, we're forgetting here, that by default, UAC elevations occur on top of Windows Vista's Protected Desktop.
As many here know, the Protected Desktop isolates UAC events and locks a computer from any other action - other than the user's assessment of the event. It forces users to properly evaluate their actions, while it protects a system from any changes.
While the local security policy enabling the Protected Desktop may be turned off, it is not recommended. And candidly, once a machine is set up as a user wishes, the IC opposite UAC events is very infrequent. Our own customer studies were pretty straightforward - we asked, after a month of use, "who among knows what this is <displaying various UAC events>?" - only one user had seen any kind of UAC event at all - the rest were simply "using their PC's"
I submit that Vista's Protected Desktop, isolating UAC events and focusing the user's attention, will reduce the IC related to "mindless responses" to such events and...
Second/Finally, give users some credit - I assess users are becoming increasingly aware of the need for better computer security and very few users will have no knowledge of UAC events - if they do, they will click on the embedded links for more information about the event being escalated.
|
#11 By
32132 (142.32.208.234)
at
4/24/2007 5:06:49 PM
|
#9 I use a password protected screensaver, even at home.
"Most users will allow visiting relatives to use their PC."
I give them a non-privledged account.
"Without password protection, for installs, these machines will ALLOW much of the same crap as XP to be installed. "
Only if you choose to run as an Admin without a password protected screensaver.
I think Microsoft has recieved enough grief over UAC (which I still think is an excellent idea) without adding a password.
I suspect you are just regurgitating the FSF/Apple talking points:
FSF: UAC is too much of a burden.
FSF:UAC isn't a big enough burden.
FSF: Vista sucks because UAC is [too much] [not enough] of a burden (choose one).
|
#12 By
23275 (172.16.10.31)
at
4/24/2007 5:23:05 PM
|
#11, Great idea on the account.
One of the things our WMC customers love is how we set up a "Visitors" account for them - and then using Vista's Parental Controls, restrict what the account may do.
This way, garndkids may use a PC w/o exposing it, or more privileged profiles. It works, great.
|
#14 By
32132 (64.180.219.241)
at
4/24/2007 11:05:38 PM
|
#13 From the comments:
"Installer Detection is primarily designed for backwards compatibility, it's purpose is to scan the name and resources of an EXE to determine whether an application is "likely" to be an installer program. If Vista thinks it is an installer then it is assumed that admin privileges will be required and the user is prompted to run the program with the required privileges.
An executable is assumed to be an installer if the executable name or description contains the strings "install" or "setup".
Installation programs designed for Vista use Manifest files to let Windows know that they require admin privileges, pre Vista installations won't contain this information. Without Installer Detection old installation programs would never have admin privileges and would always fail.
User Access Control (UAC) ensures programs do not have admin privileges by default which does help prevent SpyWare but Installer Detection has nothing to do with SpyWare prevention."
"Contrary to the article though, any files not named setup or install are not "let through" - they don't get admin privellages so can't do any/much damage. If, when they run, it turns out that they want to do some administrative stuff, that is when Vista will ask the user to grant those privellages to the program.
Just a little fact checking required by El Reg required here."
fact checking? Register? Ha ha.
|
#15 By
7754 (75.72.156.204)
at
4/25/2007 12:36:42 AM
|
#13: As Parkkker pointed out... ridiculous. This is just absurd reporting.
Reg Reader Mike, a C++ developer, discovered the behaviour after spending days trying to work out why just some of his projects required elevation (admin rights) to be run on his Windows Vista machine.
No, let's get it right. *ALL* installers require admin rights. The difference is that Vista *PROMPTS* (via UAC) for programs that it detects as installers (as anyone that has used Vista can attest). For those programs that are not detected as installers, they are *NOT* given a prompt, and *NOT* given admin rights.
This is easily verifiable with a little logic. The Program Files directory does not allow write access to non-admin accounts. If you don't receive a UAC prompt, admin rights are not given, and the installer cannot write to Program Files. The article is total misrepresentation of the feature. The truth is that the feature attempts to detect when an executable is not just an executable, but an installer--in which case it gives the UAC prompt.
And folks wonder if there is FUD out there about Microsoft? No... the Latch-types just soak these lies up, repeat them to their friends, and on and on the cycle of misinformation goes.
|
#16 By
2459 (69.22.113.215)
at
4/25/2007 2:10:50 AM
|
The difference is that Vista *PROMPTS* (via UAC) for programs that it detects as installers (as anyone that has used Vista can attest). For those programs that are not detected as installers, they are *NOT* given a prompt, and *NOT* given admin rights.
This part is correct.
*ALL* installers require admin rights.
This is not true. Installers that touch protected system resources such as Program Files or HKLM, require elevation (and note that this does not give them access to system directories -- system files are protected by Windows Resource Prtection, and changed only via the Trusted Installer). You can create an installer package that only touches per-user resources (ClickOnce is the best example, but this can also be done with MSI and unmanaged code), and thus installs without requiring elevation.
Adding to previous comments about Cancel/Allow -- this is called Admin Approval Mode and can be changed to prompt for a password on Admin accounts just as is done for non-Admin accounts, but it does not increase your security, just the amount of typing you do. A seperate account for visitors, as suggested above, is a much better solution as it also keeps the visitors from messing with documents and other files you have under your regular account that don't require elevation to access/delete. Win+L is also your friend.
This post was edited by n4cer on Wednesday, April 25, 2007 at 02:13.
|
#17 By
7754 (216.160.8.41)
at
4/25/2007 10:11:34 AM
|
#16--sorry, I wasn't thinking of ClickOnce and the like, but traditional installers that put their files in the Program Files directory. The point (as you point out as well) is that this isn't going to bypass any standard user permissions via some implicit UAC prompt acceptance based on the filename of the executable--system files still do not have write access. All the filename is used for is to prompt for admin approval if it thinks the program is an installer and will likely require it if it's going to install successfully.
|
|
|
|
|