What's the scope of the vulnerability?
This is a privilege elevation vulnerability. A malicious user who has the ability to interactively log on to a system and run code of her choice could seek to exploit this vulnerability and pose as any user on the system, including any administrator or the operating system itself.
Because this requires the ability to logon interactively and run a program, the systems most likely to be affected by this vulnerability are client systems and terminal servers, which regularly allow end-users access to the system directly at the keyboard. Internet servers, file and print servers, and application servers such as SQL servers usually restrict the ability to logon interactively, and thus are less likely to be affected by this vulnerability.
What causes the vulnerability?
The vulnerability results because of a flaw in how access to the debugging facility in Windows is validated. Due to a flaw in how requests to attach to the system debugger are authenticated, it's possible for unauthorized programs to gain access to it.
What is the debugging facility in Windows?
The debugging facility in Windows provides a way for system administrators and developers to troubleshoot programs running on Windows.
The Windows debugging facility differs from those found in development environments such as Visual Studio in that it allows for viewing and analysis of the code as it is running on the operating system in real-time. This can help developers and engineers to view and diagnose issues that are specific to a particular machine or configuration by allowing them to interrogate the code directly on the system.
How does the Windows debugging facility work?
At the root of the ability to debug code when running is the ability for one program to "attach" to another. In almost every case, this will be a debugging program or debugger, that then connects or "attaches" to the running program, or debuggee.
"Attaching" provides the means by which the debugger can then control the program being debugged. Since the process of troubleshooting requires the ability for the debugger to completely manipulate the debuggee program, the debugging facility grants the debugger the same level of control over the running program as it has itself.
What's wrong with the debugging facility in Windows?
Before allowing a debugger to attach to another program, the Windows debugger ensures that the debugger has the appropriate privileges. However, there is a flaw in how the authentication is performed, with the result that a program could be able to attach to the debugger without having the proper privileges to do so.
What could this vulnerability enable an attacker to do?
One of the capabilities that the debugger grants to applications that attach to running programs is the ability to command the running program to in turn launch new programs. When these programs are launched, they run in the security context of the launching program.
This means that this vulnerability could allow an attacker to run a program of her choosing on the system with the same privileges as any other program currently running on the system. Since a number of programs run on the system in the context of the operating system, an attacker could use this vulnerability to make her program run as if it were the operating system.
A program run in this security context would have complete control over the machine and would be able to take any action that the operating system itself could take. This includes but is not limited to adding accounts with administrative privileges, deleting critical system files, and changing security settings.
How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by writing a program that would attempt to connect to the debugging facility in Windows in a way that exploits this flaw. The attacker would most likely have her program then attempt to connect to a well-known program that runs with SYSTEM level privileges and command that program to launch a program of her choice.
Because this cannot be exploited without the ability to logon and the ability to introduce hostile code to the system, best practices that limit users' ability to logon and load programs, in accordance with the rule of least privilege, can mitigate against the chances for a successful attack.
Would this give an attacker control over the network?
In most cases, this would not. However, it will depend on the machine on which a user has logon rights. For example, if an unprivileged user were able to logon to a domain control and exploit this vulnerability, she could use this to achieve administrative privileges on the domain itself.
However, because domain controllers contain sensitive, network-wide information like this, they are usually configured in accordance with least privilege best practices and, thus, non-administrative users do not have the ability to interactively logon to them.
What does the patch do?
The patch eliminates the vulnerability by implementing proper validation for requests to attach to the debugging system.
