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.
I care about security. A lot. I do my banking on my home PC and any kind of fraud or identity theft has the potential to make my life hell. Still, not only do I not run Vista (except on a laptop which it came pre-installed on and which I dual boot with XP as default) but the first thing I do is turn UAC off. It's not just painful, it's no more secure than putting 100 locks on your front door. Burgulars and home invaders can still kick the fucking thing down, only now it takes you an hour to get into your own home. Microsoft has lost the plot in recent years. Changes to Office, a dud version of windows with almost nothing new and lots of DRM shite, changes to poiicy in everything from OS to Office to gaming. None of it friendly to the end user. They're large enough that the jury's out as to whether they'll sustain the hit or go down but they're making their systems undesirable to work with.
These posts express my own personal views, not those of my employer
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.
Well... serves them right for missing the point completely.
...) which is then accessed by unprivileged (userland) interfaces. If they worked around anything, it was basically just their own stupidity. Why do they blame some security put in place to prevent them from making the stupidity in the first place.
1) Not everybody runs as and Administrator. There are people that are savvy about their computers AND their security - i.e. not running as Administrators and, gasp, possibly even using dual-boot.
2) If you make application that simply assumes that everybody runs as and Administrator and cry foul when suddenly your favorite OS provider comes to senses and makes you stop doing that, then you're simply a bad programmer. Bad, bad programmer.
3) Wow... what a concept: you make a privileged system component (device driver, service, daemon,
4) If they think they're high-tech, then they should look around. UNIX had been doing the same since at least '90s, after suddenly realizing that SUID root isn't always a good thing.
5) Maybe they should find something else to do. Your average Indian does better job than they ever thought possible.
>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.