A recent press release from a competitor made some ill-educated statements about Microsoft User Account Control (UAC) and other user mode solutions that control application privileges. The article picked up on a weakness in UAC that has been publicly known since the beta of Windows 7, and then went on to suggest that user mode solutions are not capable of managing application privileges securely and that elevated processes can only be protected at the kernel level.
This is a not only a naive statement, but one that is categorically incorrect. I will provide clear facts to dispel this fallacy, as I explore the internals of UAC and Avecto’s own privilege management solution, Privilege Guard (Edit: now Defendpoint).
As an experienced kernel level developer, I find comments of this nature extremely irritating, as it shows a complete lack of understanding of kernel level drivers and I believe that vendors have a duty to educate and not mislead the market.
Microsoft UAC Architecture
I will begin by addressing UAC, which has a similar architecture to Privilege Guard, as both are implemented in user mode. UAC comprises the Application Information Service (AIS) and the consent.exe program, with the latter responsible for prompting the user securely. At this point, I hope I don’t need to defend Microsoft’s ability to implement kernel level components in the operating system. The simple reason UAC is implemented in user mode is because there are no advantages to implementing it in kernel mode. UAC’s closest predecessor on Windows XP, “Run As”, is also implemented in user mode, through the Secondary Logon service.
Adding unnecessary code to the kernel simply increases the chances of system stability issues and it is a complete misnomer to suggest that code should be implemented in the kernel because it’s more secure. There are many critical security components in Windows that run as system services, because they do not require kernel level components to perform their role. Microsoft themselves had a big drive in Windows 7 to simplify the kernel, removing many of the complex interdependencies and reducing the amount of kernel code, which resulted in MinWin.
There is no good reason for an application privilege management solution to exist in the kernel because all of the APIs that are used by a privilege management solution can be accessed securely from a system service running in user mode. A kernel implementation merely introduces unnecessary stability risks, which is why Microsoft UAC and Avecto Privilege Guard are both implemented in user mode, as system services.
If you are interested in finding out more about the architecture of UAC then I would highly recommend that you refer to Windows Internals, 5th Edition, by Mark Russinovich and David Solomon.
UAC Slider and Code Injection Vulnerability
As for the infamous UAC vulnerability that has been in Windows 7 since the beta, it should be understood that this is purely a configuration issue and all security solutions are only as strong as their policies. The UAC slider is a compromise between security and usability, and it’s unfortunate that UAC can be compromised at any setting other than its most secure setting, where the user is always prompted. Even if UAC was implemented in the kernel, it would suffer from the exact same issue, so don’t be fooled into thinking this is an architectural problem, as one particular vendor would have you believe.
The issue arises because the default setting of UAC will effectively trust all Windows components, allowing them to perform administrative functions without gaining consent from the user. Unfortunately, this allows an arbitrary application running in the user’s session to inject a thread into any trusted Windows process, such as explorer.exe, and then invoke calls to elevated COM methods that will not prompt the user. Without becoming overly technical, this can be used to run an elevated application without the user’s consent. It’s important to understand that UAC is still intercepting these elevated requests, but it is simply letting them through without prompting the user because the calls are initiated by a trusted Windows process, albeit by a rogue thread.
To suggest that UAC and other privilege management solutions will suffer from this problem unless they are implemented at the kernel level is a misconception, and to further suggest that these types of problems can never be fixed or patched is frankly laughable. Microsoft chose not to fix this weakness in UAC because it would mean a radical rethink of the UAC slider, in terms of how much of the operating system is trusted. This is purely a limitation of UAC’s configurability and its lack of granularity. Microsoft clearly state that the slider setting will always be a compromise between security and usability. If your over-riding concern is security then the slider should always be set to its most secure setting, which is to always prompt the user for consent.
Avecto Privilege Guard Architecture
Avecto Privilege Guard shares an almost identical architecture to UAC, where a system level service is responsible for managing the elevation of processes, in conjunction with a number of supporting components, such as Privilege Guard’s secure messaging executable, which provides similar functionality to the consent.exe component in UAC.
Unlike UAC, Privilege Guard allows elevation of applications without giving the user access to an administrator account, which is a more suitable solution for corporate environments. In addition, Privilege Guard has very granular policies, as opposed to a coarse slider, so there is no need to configure broad sweeping policies that would allow trusted Windows components to perform elevated operations without the user’s consent.
Early this year we released a security update for Privilege Guard, which tightened the security applied to a user’s processes, to provide protection against potential code injection threats when weak policies are in place. That said it’s important to follow best practices and ensure that only applications that require administrative rights are added to the Privilege Guard policies.
In some situations it may be appropriate to prompt the user before elevating an application, either to obtain their consent or to warn them of their actions. This can be achieved through Privilege Guard’s custom messaging facility, which utilizes the secure desktop to ensure that messages can’t be tampered with by applications running in the user’s session.
I hope that this post has been informative and explained why Microsoft UAC and any other application privilege management solution should reside in user mode.