Slashdot Log In
Coding Around UAC's Security Limitations
Posted by
kdawson
on Sun Apr 27, 2008 04:02 PM
from the bounce-pass-out-of-bounds-while-the-ref-isn't-looking dept.
from the bounce-pass-out-of-bounds-while-the-ref-isn't-looking dept.
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.'"
Related Stories
Submission: Coding Around UAC's Security Limitations by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Where have I heard this before? (Score:4, Insightful)
Sounds like it was written by Homeland Security and the TSA.
Re:Where have I heard this before? (Score:5, Insightful)
The so-called work-around described in TFA:
Gee, sounds to me like UAC is working exactly the way it should!
Parent
Re:Where have I heard this before? (Score:5, Funny)
Gee, sounds to me like UAC is working exactly the way it should!
Parent
Re: (Score:3, Insightful)
Any installer can stick a service in there that does privileged tasks, and that means UAC is a thin layer that's easy to work around.
Re: (Score:3, Insightful)
Except nearly all installers use admin privileges, because the Program Files directory (to name just one) isn't per-user. Windows really isn't structurally designed for per-user installation, although MS have tried it's still half finished. Users know this, and always click yes on installers when prompted.
So it's just like /bin, /usr/bin and /Applications, then ?
Any installer can stick a service in there that does privileged tasks, and that means UAC is a thin layer that's easy to work around.
How is th
Re: (Score:3, Interesting)
In fact 99% of applications shouldn't need an installer for OS X. Just a drag to the
MSFT has turned a single user OS and tacked on multi user support, and then multi user security. OS X, and every *nix are Multi-user OS's. I not only have applications but also user specific applications
Re:Where have I heard this before? (Score:4, Insightful)
well /Applications is for everyone. your supposed to install it there. Any where else and your app is misbehaving anyways.
Exactly. Just like %PROGRAMFILES%.
MSFT has turned a single user OS and tacked on multi user support, and then multi user security. OS X, and every *nix are Multi-user OS's.
False. Windows NT is, and always has been, a multiuser OS.
I not only have applications but also user specific applications stuff that only I can run, and stuff that only I can see.
And you can do exactly the same in Windows.
You shouldn't have to be an admin to install a web browser, word processor , or spreadsheet. You should only be an admin if your installing it for everyone.
So, just like Windows then ?
Parent
Re:Where have I heard this before? (Score:5, Insightful)
False. Windows NT is, and always has been, a multiuser OS.
I've long thought that the single vs multi-user nature of Windows NT and Unix has more to do with user expectations than technical limitations.
Unix users were brought up on multi-user envoronments. root had to do stuff like install system-wide apps, printers etc.
Users never expected to be able to do this, and aplications developers coded knowing these limitations.
Windows users, on the other hand, evolved out of DOS users (please note that I'm talking about users not the underlying codebase). DOS users have always had unrestricted access to their system, and this expectation was inherited by modern-day Windows users.
Equally importantly, application programmers did not code with these limitations in mind.
What you end up with is a platform that's technically perfectly capable of being multi-user, but hamstrung by user expecteations and badly designed applicaitions.
Parent
Re:Where have I heard this before? (Score:5, Insightful)
If Microsoft had indeed taken the NT kernel and built a sensible operating system above it, it would have been a multiuser system, but they didn't. Instead, they took the entire DOS and Windows 3.x world and put the NT kernel underneath it. Technically speaking, they rather tacked a single-user mindset and framework on top a multiuser kernel, making a single-user operating system. Since the NT kernel basically was written to supplant Windows anyway, it isn't entirely biased to argue that multiuser support was tacked onto Windows.
Of course, I am still not arguing against the NT kernel. Microsoft could just as well have done the same thing with the Linux kernel as well, and the result would have sucked as badly. In fact, I don't know very much about the NT kernel internals (since the documentation isn't quite as easy to get at as it is in Unix), but I would guess that it isn't an entirely bad idea at an operating system kernel. Unfortunately, the kernel alone doesn't make an operating system, and Microsoft decided to build a basically single-user system on top of the kernel.
Parent
Re:Where have I heard this before? (Score:4, Insightful)
A number of applications do this by default and will complain or
just plain bail out if you try to install them as root.
Also, something like
users can create new directories in it but not necessarily stomp
on each other.
On other platforms, services tend to not be installed as superuser.
The fact that none of this occurs to you just shows how ingrained
the whole "run everything root" idea is in Windows user culture.
Parent
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...
Parent
Re:Where have I heard this before? (Score:5, Informative)
Parent
Re:Where have I heard this before? (Score:5, Insightful)
-The base filtering engine used by the Windows Firewall
-Computer Browser keeps track of other computers on the network
-Plug and Play
-Print spooler
-Event log
-Task scheduler
-Firewall
If these things didn't autorun, I'd have a pretty different system. That or everything would run as an administrator and we'd be right back to Windows XP with the same problems we had before.
Parent
Re: (Score:3, Insightful)
What problems? I run a network of about 80 XP machines. They all run fairly well--aside from the occasional failed Windows Update. Recently someone introduced a Vista laptop to the network. It can't print because the print spooler constantly crashes (with all 5 of the variety of printers on the network), if you plug it in to the network at one site it flat out refuses to talk to anything--even after trying for 45 minutes to get
Re: (Score:3, Insightful)
The author of the article basically lauds XP's "everybody runs as an administrator" scenario as if it was a good thing, then goes on to complain that Microsoft forcing him to play by their rules rather than by his own is somehow a bad thing.
In other words, system h
Re:Where have I heard this before? (Score:4, Interesting)
Other than that, the IPC primitives Win32 provides (message queues, pipes, etc.) are about the same complexity than UNIX's and really shouldn't take that much code.
Parent
Re: (Score:3, Interesting)
Doing something sloppy and wrong is often easier and less time consuming than doing things right.
This article is just that case.
NeoSmart was getting a free ride by being bad developers, and assuming that everyone was running as admin, and that someone would always be logged into the box.
Now they're being forced to learn how to program correctly, and do things right, and yep, it takes more lines of code.
Doing things the right way almost always
Re: (Score:3, Insightful)
A Service... (Score:5, Informative)
Gee, sounds like a daemon that can be controlled from an application to me.
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.
Parent
Re:A Service... (Score:5, Interesting)
Parent
Re: (Score:3, Insightful)
Film at 11 (Score:5, Funny)
Some clever programmers found a way to force a Vista PC to obey a user with admin rights.
I'm sure there will be a patch to fix this glaring security hole in the next batch of updates.
Much as I like seeing Microsoft humbled... (Score:5, Insightful)
Re: (Score:3, Insightful)
Re:Much as I like seeing Microsoft humbled... (Score:5, Insightful)
Really? I've worked for over a dozen software companies in my career and the only two that didn't have more people in sales and marketing than in engineering and product development are also the only two that are out of business.
There are exceptions, I'm sure, but I think it's pretty normal that it takes more salespeople to sell a product than it takes engineers to design it.
Parent
Uhm, no not really a UAC work-around ... (Score:5, Informative)
Easy, but it's Not, but it is? (Score:5, Insightful)
This is the problem with Blogs. It looks like journalism, but it isn't.
Re: (Score:3, Insightful)
A terrible idea. (Score:2)
On the plus side, it's another reason for customers to buy the next version of your software...
Hmmmm, would a ISV make more money overall by deliberatly NOT being forwards compatible? are some intentionally breaking the bounds of the published SDK for this reason?
Re: (Score:3, Insightful)
The NeoSmart folks just were being lazy and assuming everyone was an admin, and that someone was always logged into the OS.
UAC is shite (Score:2, Insightful)
A privileged service is not a "hack." (Score:5, Insightful)
How is this a "hack"?
Perhaps the author of iReboot didn't see the rational for isolating a piece of code that needs to do something privileged and having it install and run in a user account which has sufficient permissions to allow it to run--but from a security standpoint this is no different than in Linux, where privileged code runs in a separate account from the user, and where IPC is used to communicate with that process.
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.
Parent
Re: (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 ha
Re: (Score:3, Insightful)
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.
Nothing to do with the OS, everything to do with the application developer.
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 de
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.
Parent
This certainly fits with my experience (Score:2, Redundant)
The problem was that we wanted the page to refresh after the upload was complete. This seems like it should be fairly simple, but with how the security works, there's not a simple way to
Re:This certainly fits with my experience (Score:4, Informative)
Parent
More fud (Score:5, Insightful)
Misleading Summary (Score:5, Interesting)
I fail to see how they drew this conclusion:
"[UAC does] not actually providing any true protection from malware authors"
This isn't a hole in the system. If applications couldn't use services running at admin or system then the entire system would be damn near nonfunctional.
I mean how would you even play music without a regular application being able to communicate up safely to the driver?
The article is fine. The person who wrote the summary didn't actually RTFA and is just trolling. They haven't justified anything they've said.
To be perfectly honest, (Score:2)
It's a lot easier to make an isolated service with rigidly defined IPC secure than it is to make something that interacts directly with the user secure.
But maybe it's all that unix poisoning my brain.
Re: (Score:2)
The problem simply is that the old registry keys for autostart have no way of specifying whether the started program should be elevated. Automatically (silently) elevating all autostart programs is a bad idea (non-elevated code can add autostart programs), and showing an elevation prompt pop up after every login is also a bad idea (I need to confirm a UAC prompt to login?). So Microsoft ended up with that "autostart program was blocked" solution. It's not a good idea, but it's less bad than the alternatives. But there was no intention of blocking programs from starting silently elevated, provided they are registered for autostart somewhere were only admins have access and where elevation can be explicitly controlled (because silently elevating just because some program says so is a bad idea). This is not possible with the Run registry key, but it's possible with the task scheduler.
Sure, the task scheduler is a service, but the tasks it starts run in the user's session, so they can display UI. There's no need to write a custom service and use inter-process communication between a non-elevated UI and a service.
This is not Vistas fault. It's just that the programmer did not know how to do it the windows way and ended up writing something insanely complicated to do the job, when something really simple would have been sufficient. Now he knows how to do it right, and in the next version he can use the scheduler to start his program, and trash all the service-fronte
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: (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 th
Re:Weird logical disconnect in the article (Score:4, Insightful)
There is _nothing_ in Windows's "security model" that requires - or even encourages - this. The problem of apps needlessly requiring Administrator-level privileges is 100% the fault of the developers of said apps and has been for nigh-on a decade.
Ironically Microsoft themselves have a proud history of producing such apps...
There's nothing "weak" about Windows NT's security model. Never has been. There were, arguably, weaknesses in the *default configuration in some environments*,
I agree, only I'd change *default configuration in some environments* to out-of-the-box defaults which are unchanged in most environments.
Parent
Re:Weird logical disconnect in the article (Score:4, Informative)
Parent
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)