The Audio Fool : Windows

Tweaking Legacy Installers

RyanBemrose — Wed, 23 May 2007 22:33:00 GMT

Last time I talked about legacy applications, I hinted at a hole in the UAC model that could be exploited by a social engineering attack. The issue lies in the "installers" category. Because it's a legacy app and doesn't have a manifest, Windows doesn't have any way of knowing whether an installer actually needs elevation to perform the install.

For the sake of backward compatibility to make sure that legacy apps just work, Microsoft decided that Windows should just elevate legacy installers by default. In most cases, this is the correct thing to do; legacy apps were developed primarily in a culture where every user was an admin, and most installers take advantage of that. So, Vista runs all legacy installers as administrator. The problem with this is that, if you're a power user, you know that not everything needs to run as administrator. The power user is savvy to the intricacies of ACLs and permissions, and knows that while his antivirus might need administrative privileges to install, the latest downloaded java game probably does not. And while you might be willing to trust the makers of that java game enough to run their silly software, you don't trust them to administer your machine.

The meat of the problem is that if Windows determines that a program is a legacy installer, then by default you're limited to only two choices: Run elevated, or don't run at all. This can be a real pain if you have a legacy program that isn't really an installer, but the heuristic treats it as one (Some archive programs are like this).

Fortunately the third option, run as a standard user, is available if you know what you're doing. On a per-app basis, you can set the __COMPAT_LAYER environment variable to suppress the installer heuristics. Just open a (non-elevated) cmd window, and type "set __COMPAT_LAYER=RunAsInvoker", and any legacy app you launch from that cmd window will run as standard user. As standard user, you can install your game applet with much less worry that it will install a rootkit or overwrite your registry. This is the recommended way to run legacy installers with low privileges.

If the recommended way doesn't work for you, you can instead shut off the heuristic entirely at a loss of some backcompat functionality. There is a switch in the group policy for Windows that disables auto-elevation for legacy installers completely. The backcompat problem is that legacy installers which really do need elevation will now crash on install, often with few clues as to why they didn't work. You have to remember to right-click the executable and select "Run as Administrator". If you don't, then you can waste a lot of time frustrated because "Vista doesn't work with this software!"

Disclaimer: As with all advanced system tweaks, make sure you Really Know What You're Doing before trying this. I am not responsible for any damage you may do to your computer. To flip the switch, run gpedit.msc, and open the tree to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Scroll down in the right pane to find "User Account Control: Detect application installations and prompt for elevation", and set it to 'Disabled'

So why didn't Microsoft just ship like this? Put yourself in the chair of my fictional Aunt Gertrude, as suddenly programs that worked fine on XP fail to install on Vista . How do you explain to Gertrude what it means when her program fails with strange and unhelpful errors messages? Even if you added a dialog saying to re-try as an admin, it wouldn't help much. We all know that users don't read dialogs. Vista broke Aunt Gertrude's program, and to the average user, that's all that matters.

Categories of Legacy Applications

RyanBemrose — Wed, 21 Mar 2007 03:57:00 GMT

If you've used Vista, you've probably been exposed to the UAC dialog. It's the security dialog that pops up when the screen goes gray, and asks you permission to perform a task which requires admin-level elevation. The idea behind it is that once programs are written for Vista (with UAC in mind), they'll sort themselves into two categories: Trusted programs that require administrative privileges (and have to pass a UAC prompt) to do their jobs, and programs that run fine without administrative privileges.

The big problem with rolling out UAC is how to deal with all of the legacy applications that have to still work. I roughly divide legacy (pre-Vista) programs into ~~five~~ six categories:

Programs that don't need or request admin privileges.

The majority of programs that run don't try to do anything forbidden like writing to system directories or opening . These programs will run fine under Vista.

Programs that don't need admin privileges, but try to access protected areas.

Even a well-intentioned app might open a system registry key for full access when it only reads the key, or might write its settings to a config file in the program files directory, because that was perfectly OK under XP where everybody ran as Administrator. For these apps that didn't really need admin access, the system virtualizes these accesses. A virtualized program is allowed to read and write as if they're writing to the system, but those changes are virtualized under the user's AppData folder.

Utilities that legitimately need to be able to modify the system.

Some programs are fully intended to administer the system, and cannot run properly in restricted user mode. Simply double-clicking this utility will cause it to fail, because the system doesn't know that it needs elevation. These legacy programs must be launched with elevated privileges in order to work. The three common ways to do this are to right-click the .exe and select "Run as Administrator", to select "Run as Administrator" in the compatibility tab of the program's properties dialog, or to run cmd.exe as administrator and launch from there. Any of these methods will get you a UAC prompt, of course. Fortunately most people don't need to run programs in this category very often.

Though many in the blogosphere would be quick to disagree, I'm actually glad that the UAC dialog is showing up here. The dialog serves two purposes for me. It is a warning flag whenever something is about to get access to my system's tender bits. It is also a reminder that whenever it isn't there, the OS is making certain that whatever's running can't get at my system's tender bits.

Malware

Some programs we just don't want to allow admin privileges to. This is the class of programs for which UAC was invented.

Installers

An installer is a special case of one of the previous categories which often needs more privileges than the program it installs. This is because installers have to set up directories, resources, and registry keys. Though it is possible to create an installer which does not need admin privileges, most legacy installers do need them and will fail without elevation, resulting in a bad user experience. The Vista planners recognized this, and made installers a special-case. Because most legacy installers will fail if they are not run elevated, Windows Vista will automatically elevate the privilege of any legacy installer.(after raising a UAC dialog, of course)

Eventually, application designers will write more Vista-aware programs, which understand how to work around the different privilege levels. A Vista-aware program can contain a manifest, which contains metadata on the program including whether or not it needs elevation. Because unnecessary UAC dialogs annoy users, software vendors will work to avoid them. In the ideal application world, then, the following happens with our five categories.

Programs that run fine without elevation continue to run unchanged. They were already doing the right thing.
Programs that don't need elevation but try to access protected areas will be fixed so that they fit into category #1. The registry access will be changed from full access to read-only, and the config file will be properly stored in the user profile's AppData directory.
Legitimate Windows utilities include a manifest with the elevation bit set. When you try to launch the program, Windows shows a UAC dialog. The program is legitimate, and you intended to administer the box, so you click yes and the program runs with admin privileges.
Malware in the post-Vista world will likely include a manifest with the elevation bit (because malware that doesn't is already blocked from affecting the system). Windows shows a UAC dialog, but you didn't intend to administer the system and you don't trust the source of the program, so you click no.
Installers include a manifest. The few installers which legitimately need to write to system locations (drivers, system utilities, debuggers) set the manifest's elevation bit. Other installers leave the bit clear, and install without a UAC prompt.

Ideally, when the only programs that legitimately require elevation are system utilities and driver installers, the user will see very few UAC dialogs, and will be vigilant for malware whenever it rears its ugly head. What a wonderful world it will be, then. :-)

Programs that explicitly check for a version of the OS.

Some programs would run just fine on the OS, except that they bind to one specific version to the exclusion of later versions. You may have seen this one, which pops up a dialog in setup on Vista saying "You must run this program on Windows XP". The program checks GetWindowsVersion equal to XP, rather than checking that it's greater or equal. For these buggy programs, there's Compatibility Mode. When you run a program in Compatibilty Mode for a given version of Windows, Vista will lie to the program and pretend to be that version, causing it to run correctly. To turn on Compatibility mode for a program, right-click the program and select Properties. In the Compatibility tab, select "Run in compatibility mode".

Next time: See if you can spot the social engineering hole in this model.

UPDATE: It seems I mixed up virtualization with compatibility mode. Fixed above (#2 and #6)

Vista Now Available

RyanBemrose — Tue, 30 Jan 2007 08:51:00 GMT

After months of waiting it's released. Go out and get yourself a copy already!

If it doesn't just work, then it doesn't work.

RyanBemrose — Thu, 14 Dec 2006 21:33:54 GMT

I'm passionate about usability, even to the point that my co-workers accuse me of whining. I can't really help it. I have to applaud products and features that streamline a task, are intuitive, and fit well into the workflow. And when a feature unnecessarily complicates the task, I have to call it out. Poor usability goes against what computing is supposed to be about. Way back in the early days of computing, BillG sold a dream to the world's people. That this newfangled invention called a 'computer' was supposed to make everybody's lives easier. It was supposed to boost productivity, make routine tasks effortless, and make complicated tasks easier (or possible). We've come a long way since then, and I'm happy to report that computers have, for the most part, done that. But as you already know if you work with a computer regularly, there is a lot more work that could be done.

There's a funny thing about most computer users that we software folks don't usually get. Most people don't get excited about technology for technology sake. My dad doesn't want to know that his data is on the C: drive, but his backups go to the D: drive. My aunt doesn't need to understand what it means to defrag a hard disk, or think about how big a buffer she need when burning a CD, and my mom doesn't want to have to care whether she has the right media codecs installed. As far as the average computer user is concerned, a computers should just work. Any time they have to think about how it works, it's not working properly.

Making computers just work is one of the design goals behind Vista. I won't say we've succeeded, but there are some pretty good examples, such as wireless networking. Want to connect? Click on the network icon and it'll show you a list of networks in range. Click the network you want to connect (and enter a security key if you haven't connected to this secured network before), and Vista does the rest. A few seconds later, you're surfing the 'net.

Closer to home (for me), we've completely changed the way that you interact with audio devices in Windows. In XP, you could open the control panel and set your sounds to your "Creative 123 audio chipset" or direct an application to record from your "SoundMax XYZ 987 codec". But most folks don't understand what a 'codec' is, or think about their 'audio chipset'. Most folks don't want to understand. When I look at my 'computer' on the floor next to my desk, I don't see an audio chipset. I see a small 3.5mm hole labeled 'Speaker' or 'Line out', and so that's how Vista presents them. Instead of picking from a list of internal audio devices, you just say you want your music to go to the front panel headphone jack, and Windows does the rest.

In the future, you'll probably read more about usability here, good and bad. Building good human interaction into a program is a Hard problem, and lots of smart people are working on it. It's a problem space that I'm personally very interested in because, though I'm a programmer of some software, I'm a user of far more. And if it's difficult for me, I can only guess how it's going to be for my mom and dad.

And for my encore... Sleep.

RyanBemrose — Wed, 08 Nov 2006 23:46:59 GMT

As you've almost certainly heard by now, we've finished. Windows Vista has shipped, and our mantle has passed on to the manufacturers, who now have a little over two months to stuff a hundred million DVDs into boxes and put them onto store shelves everywhere.

For those of you outside the company, this date really doesn't mean much, because you still won't see the finished product until it's out on a store shelf. But internally, it's cause for celebration. All of the programming is finished, and the developers are now moving on to the next version. There's a pretty good Q&A with svenh up on presspass about what this means.

A couple weeks ago, Larry Osterman posted on a game he dubbed Last Checkin Chicken. What he didn't know when writing up that post was how close the "winner" would be. The apparent last checkin was a hardware compat fix by a dev on the audio team. Not only that, but the bug was found with one of my test apps, so I'm close to it. There's a part of me disappointed that I didn't help find this one sooner, thus saving the notoriety of being last, but mostly I'm just glad we were able to get the fix into the product at all.

I think November and December are going to be pretty dead around here. We're in the planning stages for the next Windows, but now is the time that many people will take long-overdue vacations, put off during the ship stages of Vista. With all these developers coming down from crunch time, one of the other devs here suggested that now would be a good time to sell your coffee stock. Me? I'm going to sleep in for a few days.

Should you use Vista? I do.

RyanBemrose — Mon, 25 Sep 2006 23:44:48 GMT

I'm completely switched over. Aside from my two linux servers, every machine I run is on Vista, and the OS isn't even finished yet. Since Beta 1 we've been asked to "Self Host" - to run Vista on our primary development and productivity machines. On early Beta 1 builds, the stability wasn't so good, and the driver support was worse. Self hosting was a chore that I dreaded. It sometimes seemed like the decision was between productivity and self hosting. The Beta 2 platform was stable enough to work, but performance wasn't that good. Still, I kept filing bugs and the platform got better.

My advice to anybody using a beta product: File bugs as early and often as possible against anything that bothers or annoys you. If you intend to use the product long-term, it pays to have your personal pain points be addressed.

So here we are at RC1. I've finally upgraded my last holdout Windows box yesterday, and am XP free. There are still some nagging UI bugs and the occasional functionality glitch, but in the age of internet patches, updates, and hotfixes, the OS is release quality. Yet we've got one more milestone to fix bugs. I'm sold, and the following is a couple of reasons why.

I like the new development features. I'm a developer, so I suppose I would. The new development features like new APIs, rewritten audio and network stacks, and the DWM make possible program scenarios that just aren't possible anywhere else, most of which haven't even been envisioned yet. A lot of these are hinted at by blogs on this site. Unfortunately, if you're not a developer, you'll have to wait a few years before software catches up, but such is the way with new platform features. Trust me, it's nice.

The new integrated features are handy. Until I started using it, I never realized how much I use integrated desktop search. I can finally author and burn CDs and DVDs from explorer (sadly, no .ISOs). Per-app volume controls are very useful.

If you only wanted one reason for upgrading, it would be the security. The more obvious security features are probably UAC, Windows Defender, and IE-low. Each of these single-handedly obsoletes whole classes of malware. The less obvious ones are infused into every OS component. This is the first Microsoft consumer OS to be released with every single line of code vetted for security before and during each coding cycle. These are the threat models that Larry Osterman talks about. XPSP2 was a big improvement over XP Gold, and Vista is far more.

Vista now sells 32-bit and 64-bit versions right next to eachother. Moving to a 64-bit OS is inevitable, so this is an important step. Especially since my next machine will be 64-bit. Now, if only 3rd-party apps would start compiling for the 64-bit platform.

Oh, and Aero Glass? Very shiny. Much eye candy. Beautiful, if you have it. Also, not really necessary. A lot of electronic ink has been spilled over having to buy new video hardware just to run Vista, but it's not true. I'm typing this on a notebook with an integrated Intel 915 Express, which, as of this writing, does not have a WDDM driver, and my experience isn't lessened. Oh, it's nice to have Glass, and it will probably become necessary in the future as more apps support it, but anybody that tells you that you have to upgrade now to the newest video card doesn't have all the facts.

Overall, I only really need the following reason for running Vista. I have to use a Windows machine. And even in its non-complete state, Windows Vista is the best Windows ever released. It's better than 2k, 9x, and Srv2003. And it's better than XP. I can't wait until release. My name is Ryan, and I'm a Windows Vista user.

The Dancing Bunnies problem and the need for application-level security

RyanBemrose — Sat, 19 Aug 2006 01:59:52 GMT

Raymond today has a discussion up about the folly of trying to set security with a granularity of per-DLL. As he explains, the moment you let something untrusted run in your process space, you cannot trust anything in the process. You cannot wall off a DLL or a section of code from the rest of the process. "That's why code is not a security principal," he concludes.

But you can wall off a process. There is an ACL associated with each running process (via its user context), so you can restrict what code can do depending on its process. More on that in a moment.

The other point Raymond drives home is that, to the system, there is no difference between the application and the user. Put another way, When an application has the credentials of a user and attempts to perform an operation, there is no good way for the system to know whether the app asked the user before performing it. Therefore, the only effective way to limit what an application can do is reduce its process ACL when the application is launched, and then limit what it can do based on that.

So consider this in the context of the Dancing Bunnies problem. There is a website which will let me download an executable to watch dancing bunnies. Conventional security wisdom says that the only way to be secure is to not download the executable. This is obviously the most secure choice, from a technical standpoint, but the technical standpoint goes on its ear when you add a user to the equation. Conventional security wisdom doesn't let me see my dancing bunnies, so I'm going to download it anyway. When I run the executable, it takes on my user token, and suddenly the website's code has the full ability to do anything to my system that I can do -- and if I'm on a pre-Vista OS, that means admin access. What's worse, it probably won't even bother to ask whether I want my system owned. The nerve!

So somehow we lost the most secure option (not downloading the exe) because it wasn't acceptible to the user -- I couldn't see my dancing bunnies. Without that most secure option, the only one left is the least secure (system owned). What I think we need is another status for the app. I want an execution option that says "I want to see my dancing bunnies, but I don't want my system owned". UAC on Vista does a very good job of preventing the system owned result, but a malicious program can still do a lot of damage. Even better is the "low" security context that IE7 runs in by default on Vista, which can only access certain directories and APIs. This mode is effectively the application-level security that I spoke of earlier.

What I'd like to see, as a partial answer to the Dancing Bunnies problem, is the ability to download and save an app from the internet, and have that app marked as "untrusted". When I launch the app, it launches in some sort of sandbox similar to the "low" security mode with restricted process permissions. If it's coded correctly then it shows me my dancing bunnies. If it's malicious, then I haven't lost anything. This is something that users will buy into.

Of course, we still have the social engineering problem of exes that tell the user they can only see dancing bunnies after they click away that nagging UAC prompt. The way to fix that is to convince them that Microsoft is more trustworthy than Ye Olde Maliciouse Website. When I come up with the solution to that one, I'll let you know.