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.'"
I'm sorry but their "bypass" was to create a service running in an elevated state and then communicate with said service via exposed APIs.
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.
What you find in Vista (not XP unfortunately) is that a lot of the services that run with LocalSystem now run as "restricted" localsystem. They've profiled each service and figured out exactly what access it needs to run, and then granted that service those rights and no others. So while it looks like LocalSystem/Network Service it actually has reduced rights. Which is a good thing.
I've written lots of applications that use COM for IPC and it's incredibly easy to do... just define an object and it's methods on one side... instantiate and call in the other. If you use the right COM bindings (MFC, ATL, Visual Basic, JScript, etc) the code it's quite clean, short and to the point. ... granted, COM has a very steep learning curve, just like RPC, Corba, etc... but I guess that although it wasn't the path I took, you can use just a small portion of COM (over ATL or VB) for IPC without worrying about the underlaying structure, apartment models, class factories, reference count, etc.
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.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.