Tuesday, November 03, 2009 9:21 PM/EST
Chester Wisniewski, senior security adviser for Sophos Canada, Nov. 3 published on his blog a rather damning account of Windows 7 security and User Account Control.
In his examination, he found that seven out of 10 malware samples tested were able to successfully run on a fresh Windows 7 installation employing the new, quieter UAC that is the default in the new operating system.
Ugly. Not a surprise, but ugly. Also, it's not a test designed to be passed.
In essence, the default setting for UAC in Windows 7 is, "Don't notify me when I make changes to Windows settings." So when Wisniewski downloaded malware samples onto the PC and ran them--simulating a user intentionally downloading and running a file obtained via e-mail or the Web--he was purposefully making changes to Windows settings, so UAC did not prompt him. The system acted as it was told to do, so it should come as no surprise that UAC did not block the malware installation.
The shortcomings in Windows' 7 UAC design have been apparent for quite some time. In my August review of the RTM of Windows 7, I postulated that "the new settings--including the new default--serve to worsen the security protections UAC affords," a theory that seems to be borne out by this study. Basically, with Windows 7's UAC, Microsoft decided to step back from trying to save users from their own mistakes--leaving that role primarily to third-party security solutions.
Indeed, Wisniewski comes to the same conclusion, that, "You still need to run antivirus on Windows 7."
Leaving that argument aside, what Microsoft should be doing is figuring out ways to change the way people compute. That default UAC setting is only the default setting for users who are part of the Administrators group. Users that only have standard User privileges instead, by default, get the strongest option--to be notified when the user or programs make changes. And since the standard user doesn't have rights to automatically elevate their tokens in order to make the change anyway, they would have to enter over-the-shoulder administrator credentials to make the change.
Certainly, I like to see security companies--or even Microsoft--publish the results of similar tests, focused on systems operated in a more secure manner. Malware running on an unprotected system with admin privileges is not news, while malware that runs and stays resident without admin rights certainly would be.
Thursday, August 20, 2009 7:56 PM/EST
By no means have I done an exhaustive check of all the anti-malware companies yet, but it looks like virtual machine licensing is going to be a major differentiator between various products as we move toward the release of all the 2010 software suites.
Today, Sunbelt Software touted via its blog that Sunbelt's licensing applies per computer, not per instance.
"Our company policy is a single-user license applies to one box, and any VM sessions on that box. A single-user license is set up to allow multiple installations on one box with W7 and XP mode both running."
This becomes a pretty important distinction once Windows 7 and XP Mode come into play for those running Win 7 Ultimate, Professional or Enterprise (or any other hypervisor for that matter). Personally, I quickly found that a migration from Vista32 to Win7 x64 necessitated that I run a VM only for my legacy Cisco VPN client, which won't work on 64-bit machines.
Unfortunately, not every security suite is going to license VMs in the same manner. I'm currently testing one product (I can't say which due to an embargo), and I just learned that protecting the host and the client will count as two licenses.
So, as you evaluate what security to put on your new Windows 7 PC come October, remember to weigh how much security is going to cost you, if you need to spin up an instance to support some legacy application.
Friday, August 14, 2009 8:19 PM/EST
One thing new with Windows 7 RTM since the Release Candidate -- is that the default administrator account is now disabled by default (the account was also disabled in Vista SP1 and SP2). When Windows 7 (Ultimate x64 in my case) is installed, the user creates a personal log-in and password, and this account is automatically made part of the local Administrators group. At the same time, a second Administrator user account gets created in the background with no password, but the account is disabled by default. In the RC this account was enabled, but no more. *
I discovered this little tidbit as I configured my system for least privilege user mode. After I slid the UAC (User Account Control) slider bar to maximum protection, I logged into the Local Users and Groups dialog to change the name of the Administrator account and add a password. Unfortunately, I failed to notice the account was disabled by default. As a result, once I deleted the Administrators group membership from my personal account, I found I had therefore locked myself out of the ability to access any UAC-protected tools -- such as Computer Management or Add/Remove Programs. As there was no active Administrator account in my case, both UAC and RunAs were useless and there was no active Admin account with which I could actively log on.
Then I learned Microsoft only went halfway with this significant change, and, man, the other half is really badly done.
As a last recourse, I rebooted and hit F8 during the OS load to get to the Advanced Boot Options. I selected Windows 7's new "Repair Your Computer" option, which loads a slimmed-down user interface for the recovery tool. I selected my account with my limited rights credentials from a drop-down menu and was presented with a single option: Startup Repair. The tool ran a series of diagnostics -- it didn't say what at that time, but I later learned it was running file-system, disk and registry validation checks -- then presented me with the option to restore the computer using System Restore. I was not allowed to select which System Restore settings to use, although the system appeared to use the most recently saved settings.
The restore was completed, and voila, permissions were returned to a workable state.
Upon further investigation, however, I found that in the preboot environment I could also log in and effect changes using the otherwise disabled local Administrator account, but only under certain circumstances. Specifically, when no other local administrator accounts are present, the disabled Administrator account appears in the log-in drop-down box and can be suddenly be accessed. And as I mentioned above, even after all these years of Microsoft receiving criticism for this lack of attention to security, the Administrator account has no password by default.
An admin logging into the recovery tool has a lot more options at his or her disposal, too. As an admin, I could perform the same auto-fix tests, perform System Restores with the ability to select the settings to use, run a System Image Recovery event to restore from a disk backup, run memory diagnostic tests or access the command line for more possible actions. And from the command line I could change drives over to the main drive (from the pre-executable one) and read anything I wanted, even copy it to a USB stick and take it with me.
Certainly, we know that a data thief with physical access to the machine typically means game over. Boot to a LiveCD or a USB stick that can see into NTFS (NT File System), and thieves can take whatever they want. The usual countermeasures are then to block boot from CD or USB at the BIOS, and put a BIOS password on the system. But, heck, now Microsoft puts in the hacking tools for you -- no need for third-party boot media.
Users could protect themselves by fully encrypting the drive with BitLocker so the intruder only sees garbage. Oh, wait, that's only for Ultimate and Enterprise customers, not the vast majority of people who will use Home Premium. Never mind.
Honestly, it's hard to take Microsoft seriously about the security of its products when you can drive a bus through some of their holes. I know the circumstances of this case were a little unique (who among you plan to remove your admin rights?), but in my book, disabled should mean disabled. Microsoft should NOT be creating as default an admin account with no password, then opening up the account for use in certain situations.
Word to the wise: Even though that admin account is disabled, do yourself a favor and put a password on it. You probably won't regret it.
* Updated to correct some comparisons with Vista.
Friday, February 20, 2009 3:58 PM/EST
One of the more frequent comments that I have gotten from readers in reaction to my January look at the first beta of Microsoft's forthcoming Windows 7 desktop operating system was that Windows Vista and--guilty by association--Windows 7 got in the way of people doing real work.
Only a few have bothered to elaborate on what they mean by this, but I suspect that those with this complaint fall into two camps: those uncomfortable with the new UI and menu structure introduced in Vista, and those who have run afoul of the User Account Control security functions.
UIs are not natural things. They are artificial constructs borne out of committee and group think, and are therefore never what any one specific person wants. They're a consensus. Whatever is left is something most people essentially memorize and get used to. Personally, I stuck with the Windows 2000 interface for the last nine years, but Windows 7's new taskbar and start menu really appeal to me.
On the other hand, I tend to view UAC in the same way I view public urination laws. Yeah, following the rules of either may slow me down from my daily appointments, but for the sake of health (staying free from malware), sanitation (keeping the registry and file system uncluttered), and social mores (not spreading a worm or botnet to others), the laws--and the feature--are worth having on the books.
I've been using Vista on my work machine for a full year now, utilizing UAC the whole time. Not only is UAC active, but I require an over-the-shoulder password in order to make a change (as in, I am not an admin and therefore need a secondary admin account for approvals). In that time, I've learned exactly which applications behave as I think they should under UAC, which applications have idiosyncrasies or problems (with security products being among the worst offenders due to their constant need for updates), and when I can expect to need those admin credentials.
My count of UAC prompts over the last seven days? Six, and all occurred as I intentionally upgraded software. I wonder if six in a week qualifies as getting in the way of real work?
A lot of people hate UAC because the feature breaks legacy applications. But this is not the fault of Windows really, but of the third-party software. It's bad code, written by lazy, hurried, or unconcerned developers adhering to development standards 10 years in the rear view mirror. I can't tell you how many product vendors I have talked to who have given me the same spiel about their software, saying in essence, "We'll get the features right, then fix the security later." And I am galled whenever I read about developers with the temerity to complain about the new security features in Windows getting in the way of the fast development of their code.
Always operating your computer with full administrative permissions has always been a broken model. No other mainstream operating systems encourage operating as root, and with Vista, Windows finally is trying to join everyone else. But users continue to balk, because they have grown accustomed to working by the rules of their broken model.
Stated plainly, sticking with Windows XP because later Windows break applications only serves to reward and enforce those sloppy development practices. In truth, it is not just Vista (or Windows 7) breaking those applications. Windows XP, like Windows 2000 before it, could certainly be operated by limited rights users, and a whole cottage industry has sprung up in the Windows eco-system just to solve permission problems for limited rights users on those systems.
To make an apples-to-apples comparison, whether Vista/Windows 7 is to blame for your loss of productivity, or whether it is actually due to bad software, I ask those steadfastly sticking to Windows XP to remove your administrative credentials from your user account. Get familiar with the "Run As" command, with multiple logins, and dealing with application permissions. Then make your assessment.
Alas, I admit I have been complicit in furthering these bad practices with shortcomings in my own testing and analysis for eWEEK. Therefore, I make this pledge -- from here on, in my reviews, I will ensure all software I test designed to run on Windows desktops operates as advertised with only limited user rights. And I will call out those that fail this litmus test.
Maybe together we can put a stop to the garbage foisted upon us.
|