Slashdot Mirror
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.'"
Sounds like it was written by Homeland Security and the TSA.
It must have been something you assimilated. . . .
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.
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.
Negotiating contracts with ATI and nVidia for a share of videocard sales does take time, you know.
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.
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.
Which is fine, provided the interfaces exposed by the daemon aren't themselves insecure.
>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.
...
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.
The NeoSmart folks just were being lazy and assuming everyone was an admin, and that someone was always logged into the OS.