Coding Around UAC's Security Limitations 334
Mariam writes "Free software developers from the non-profit NeoSmart Technologies have published a report detailing their experience with coding around Windows Vista's UAC limitations, including the steps they took to make their software perform system actions without requiring admin approval or UAC elevation. Their conclusion? That Windows Vista's improved security model is nothing more than a series of obstacles that in reality only make it more difficult for honest ISVs to publish working code and not actually providing any true protection from malware authors. Quoting from the post: 'Perhaps most importantly though, is the fact that Windows Vista's newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security. Any program that UAC blocks from starting up "for good security reasons" can be coded to work around these limitations with (relative) ease. The "architectural redesign" of Vista's security framework isn't so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.'"
A Service... (Score:5, Informative)
Gee, sounds like a daemon that can be controlled from an application to me.
Uhm, no not really a UAC work-around ... (Score:5, Informative)
Re:A privileged service is not a "hack." (Score:5, Informative)
In fact the first response where it was announced is:
Uhh... I'm running an admin application on startup automatically all the time, there's no need to create a service or anything. Just use the Task Scheduler to start the application, Trigger=At log on; And select "Run with highest privileges".
MS had NEVER set out to prevent elevated applications from running at startup.
Weird logical disconnect in the article (Score:5, Informative)
The "Gory details" portion of the article gives a pretty good explanation of the work they had to do to make iReboot access high-permission OS features via a low-permission client. I have no idea how they got from there to "Any program that UAC blocks from starting up 'for good security reasons' can be coded to work around these limitations with (relative) ease." What they seem to be missing is that there was an installer in the loop---an installer that requires admin privileges. This is exactly the part of the process that UAC is trying to force upon Windows developers!
The most significant problems with the Windows XP security model are as much social as technical. Because the model didn't make it easy to get "serious work" done as a non-administrator, most people are running as administrators most of the time. This creates a whole culture that is very vulnerable to social engineering---simple games are being run at the same permission level as complex drive-recovery utilities and keyboard loggers.
By having people run low-privilege by default and escalating when necessary, the UAC model forces developers to be a little clearer about what their applications are doing (since things that "just worked" in WinXP now require permission in Vista). My understanding is that the way iReboot works now is the way it should always have worked, under the Windows OS model; the fact that it also worked if the user were running as an administrator was a happy accident. How well did the old iReboot work if I wasn't running as an administrator? If the answer is "It didn't," then, well, maybe they were doing it wrong the whole time.
UAC has some problems, but the fact that it puts more work on developers isn't one of them. The work is necessary because it is accounting for a weaker security model from the past. And developers should know that security isn't free.
Re:A Service... (Score:5, Informative)
Unfortunately, tying the desktop environment, window manager, and kernel together into a tightly integrated package will increase the damage per amount of attack vector surface area, should a single link in the armor be broken. In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group. If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root. Regardless if it's a crappy HP driver service, a hypervisor, or explorer. All that to say, the design is flawed such that not only are these things possible, but they have greater consequences than they would under other OSes.
Re:This certainly fits with my experience (Score:4, Informative)
Re:Where have I heard this before? (Score:4, Informative)
2. The part in your link that nicely sums up NSA's contributions:
The NSA also declined to be specific but said it used two groups -- a "red team" and a "blue team" -- to test Vista's security. The red team, for instance, posed as "the determined, technically competent adversary" to disrupt, corrupt or steal information. "They pretend to be bad guys," Sager said. The blue team helped Defense Department system administrators with Vista's configuration.
I can't see anything wrong with that...
Re:A privileged service is not a "hack." (Score:3, Informative)
No, because MSI runs privileged and is able to install such processes at the command of normal users - that's the hole. You get one prompt, at installation time.. but I've never seen a windows installer that *didn't* prompt for elevation. Contrast with Unix based systems where installing apps as a normal user is the norm and installing as root is an exception (indeed with OSX each user has a full set of directories for this by default, and it's rare for something to require elevation.. when it does you definately think because it's unusual).
Re:A privileged service is not a "hack." (Score:5, Informative)
If I write a service that allows any user to write to any location in the filesystem (entirely possible on any OS - for Windows, I install a LocalSystem service, for *nix, I install a daemon that runs as root) then that service has a security hole in it, and it can be used to elevate privileges from normal user to admin/root.
That's a flaw in the service/daemon, not a flaw in the OS.
Unless you were saying that you don't know if this app has a security flaw like the one I described above.
Re:Where have I heard this before? (Score:5, Informative)
Re:Weird logical disconnect in the article (Score:3, Informative)
When I said "model," I was referring to the aggregate of the actual model and the way the model is exposed for the average consumer (who in WindowsXP, is usually running as an administrator for even the simplest tasks, either due to poorly-written software or their account simply having been configured by default as an administrator). There is just too much software in Windows XP that wants administrator privileges for questionable reasons---so much that it's easier for me to just run as administrator and ignore the issue altogether.
But I do have to ask whether this is totally the fault of the developers. I'm a developer myself, and I've experimented with running as a non-administrator. Simply being forced to "Run as..." most of my development applications was enough to make me want to re-enable administrator privileges on my personal account. But I was effectively forced to re-privilege myself when I began developing an IE plugin. If there is a way to register ActiveX controls with the system as a non-administrator so that Internet Explorer can find and use them correctly, I am unaware of it. IE's reliance on ActiveX means that you effectively can't download and install plugins from the Internet without admin rights---even in such a way that the execution of those plugins would be at a non-administrator privilege level.
Incidentally, Firefox sidesteps this entire issue by allowing plugins to be downloaded into a user's Application Data directory.
So the WindowsXP security model is fairly robust as a model. But with software written by Microsoft themselves not taking advantage of it in a way that makes the end user's life convenient, there's certainly something that smells. Even if the only real substantive difference between the Windows XP and Vista security models is the addition of a more convenient on-the-fly escalation mechanism, that's saying something.
(I don't know how my example of grabbing ActiveX plugins from the Internet works in Vista under UAC. If someone has experience with it, I'm interested)
Re:Weird logical disconnect in the article (Score:4, Informative)
Why UAC is good (Score:1, Informative)
1. This is the _PROPER_ and documented way to add elevated applications
2. Adding such applications can not happen _WITHOUT_ the permission of an administrator (the installer in their case)
3. This is the same in Linux/Unix (For all Linux/Unix lovers
So don't blame UAC for being insecure - which it is not.
The only annoying feature in programming UAC is that you cant elevate from within a program. You either need to start the program with elevated rights (using a manifest) or use elevated COM components (which is more or less the programmatic way).
If you are annoyed by the frequent prompts - you can enable auto elevation using the security policy editor. UAC + auto elevation is still much more secure than UAC turned off.
BTW, Ubuntu has pretty much the same behaviour
Lies and FUD... (Score:2, Informative)
From TFA: "Microsoft can claim that Vista blocks system-modification tools from running at startup;" -- again, I'm sorry, but Microsoft does not make this claim. The steps that the developers of this product (admittedly a good one) are perfectly in line with what I'd expect a system of this nature to do: run as a service. That's *exactly* what services are supposed to be: administrative-level daemons that must launch on startup and are independent of the user account (or always require high privileges). Microsoft does not block applications requiring admin access from starting up for SECURITY -- it's done because otherwise, your computer would be stuck on the secure desktop waiting for authorization, and anyone possibly depending on the application (and anyone else also requiring elevation -- AFAIK, the AppInfo service can only request one elevation at a time) would also be frozen.
I don't see what the big deal is. I run OS X on my desktop and I see plenty of similar applications running as services, in fact, I'm pretty sure Apple's guidelines also don't allow for applications that require root access to prompt for credentials during the startup process. It's just bad user experience.
again, fix your damn software (Score:1, Informative)
This is just a huge security hole that infects your computer when the software is installed. If they did anything simple as a 'ReadFile' as the privileged user, and that you can trigger the daemon to execute it, then it just compromised your system.
So instead of creating various, new, security issues, just fix your damn software please.
Re:Where have I heard this before? (Score:2, Informative)