The recent Duqu 2.0 targeted attack used several zero-day vulnerabilities as part of its attack. One of the vulnerabilities used was CVE-2015-2360, which was fixed by MS15-061 as part of the June Patch Tuesday release. Like CVE-2015-1701, this is also in the Win32k.sys file, which is commonly targeted by attackers to bypass existing vulnerability mitigation techniques. The vulnerability lies in how windows are handled by the operating system. Some background information about this is necessary: If an application wants to show a window, it needs to perform two steps:Registering a window class. This will lead the OS kernel to create a window class object, which exists in kernel space and an application program cannot access it directly from user mode. The structure is named tagCLS. The window class object specifies the window ‘s style and behavior.Creating a window with the window class object which was registering in the previous step. The progress will lead the OS kernel to create a window object, which exists in kernel space and application program cannot access it directly from user mode. This structure is named tagWND. Registering a window class. This will lead the OS kernel to create a window class object, which exists in kernel space and an application program cannot access it directly from user mode. The structure is named tagCLS. The window class object specifies the window ‘s style and behavior. Creating a window with the window class object which was registering in the previous step. The progress will lead the OS kernel to create a window object, which exists in kernel space and application program cannot access it directly from user mode. This structure is named tagWND. Every window has a window procedure to handle window messages. The window procedure can be run in user mode or kernel mode. It depends on the window class object’s file named CSF_flags. If the CSF_flags field has the flag “Server Side Proc”, the window object’s window procedure can be run in kernel mode. If it does not have the flag, the window object’s window procedure can be run in user mode. If one application program provides its own window procedure which is not the default window procedure, the window procedure only runs in user mode: the window class object’s CSF_flags field doesn’t include “Server Side Proc” flag. Figure 1. tagCLS structure From Figure 1, we can see the tagCLS structure’s CSF_flags field is a 32-bit number. Every bit represents one Characteristic. The first bit is the flag for the “Server Side Proc” characteristic. win32.sys has a characteristic that it will switch to user mode to run some user mode callback functions to do some work which is fit for user mode. This is frequently exploited by attackers. Let’s take a look the vulnerability. The vulnerability can be summarized in the following figure: Figure 2. Vulnerable message handling process When a window message is received (for example, from WM_SetIcon), the kernel will handle the message. The process is lengthy. In the above illustration, I only included the parts which are related to the vulnerability. The vulnerability exists in the step 4: it doesn’t check that the tagCLS object is valid after it switches back from user mode and continuously does some operation on the tagCLS object. This poses a serious security risk Exploitation This type of vulnerability is not very easy to exploit, because the attacker needs to be very familiar with the working model of win32k.sys This type of vulnerability can be exploited with several common techniques; I list one possibility below: Figure 3. Possible exploit methodology After step 7, the attacker can create a window with the modified tagCLS object which has “Server Side Proc” flag. The window’s procedure can be run in kernel mode. This means that the attacker can now run their code with elevated kernel mode privileges, effectively allowing for a complete compromise of the affected system. Solutions The most effective solution for this vulnerability is to roll out the appropriate official patch. It is also worth noting that this vulnerability is only an escalation-of-privilege vulnerability. Other attack techniques are necessary to get code running on the targeted system in the first place; solutions that focus on preventing and detecting these may also be useful to administrators.