Coding Around UAC's Security Limitations

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.'"

Comments

Where have I heard this before?

[fahrbot-bot]

...Windows Vista's newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security...

Sounds like it was written by Homeland Security and the TSA.

Re:Where have I heard this before?

[dhavleak]

Sounds like it was written by Homeland Security and the TSA. That's BS and so is TFA. The part you quoted (which was in bold in TFA) is just an anti-UAC rant thrown in to get attention, and clearly it worked.

The so-called work-around described in TFA:

• - Split iReboot in two parts, a background service and a userspace client
• - Background service runs as SYSTEM or LOCAL SERVICE
• - Userspace client runs unprivileged
• - Installing iReboot now requires an installer
• - The installer requires admin privileges (i.e. you will see a UAC prompt when installing)

Gee, sounds to me like UAC is working exactly the way it should!

Re:Where have I heard this before?

[wwahammy]

No it is working as designed. To install software that will modify the system, you need to use elevated privileges. Once you have elevated privileges you can do anything you want, including installing services that autostart. This is no different than installing an additional daemon on Unix-y systems. If you feel that is a security vulnerability, how do you intend to get anything done? Just a list of some of the different services that autorun on my computer:
-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.

Re:Where have I heard this before?

[IchBinEinPenguin]

> 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'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.

Re:Where have I heard this before?

[Dolda2000]

False. Windows NT is, and always has been, a multiuser OS. Indeed -- the NT kernel is, and always has been, a multiuser kernel. That does not, however, make Windows a multiuser operating system, if I may say so. I, too, would think that the GP doesn't really know what he's talking about, but when put into another perspective, his argument that "multiuser support has been tacked onto Windows" isn't unfair in any way.

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.

Much as I like seeing Microsoft humbled...

[argent]

Much as I like seeing Microsoft humbled, the comments on the original article seem to exonerate Microsoft of being as stupid as the article makes them sound. Lazy, perhaps, but not that stupid.

Re:Much as I like seeing Microsoft humbled...

[swillden]

Having a bigger marketing department than a programming department for a software company sounds pretty stupid to me. ;)

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.

Easy, but it's Not, but it is?

[Anonymous Coward]

The "bottom line" starts off saying it wasn't easy, took much additional code, and many man hours of work. Then the next paragraph tells you it's "easy to code around".

This is the problem with Blogs. It looks like journalism, but it isn't.

A privileged service is not a "hack."

[w3woody]

So he created a service that runs with the necessary privileges to do what it needs, which communicates with a non-privileged front-end, and which requires privileges to install.

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.

More fud

[ryan_hurst]

So they created a service (daemon) that exposed a interface that had no ACL on it that allowed the caller to perform privliged opperations, they had the administrator (root) install the service and grant it administrative permissions (again, root) and then had a unprivliged application call that interface. Sounds exactly like unix to me, more over short of not having ACLs on the interface, Microsoft has white papers telling folks how to do just this. In fact a CS major would know this as "least-privliged-design" oh-no mr. bill. Only on Slashdot would this qualify as news.